CTB Very slow changing between subnodes/nodes [0.99.51]

[danieljnilson]

Hello,

I use cherrytree extensively as an electronic notebook for work (going back to 2018) on Ubuntu. It now operates slowly. Is there a way for me to enhance the speed or increase the smoothness in node switching?

My ctb file is 60mb and switching between nodes/subnodes causes the program to freeze for 5-30 seconds

I've tried "Save & Vacuum," reducing the number of backups, and limiting autosaves to every 5 minutes. Howe

Unfortunately the bulk of the file size is in the node that I am currently working in / can't separate (it consists of several small tables & compressed images). The images are of graphs that are most convenient to have integrated in.

The .ctb file & cherrytree run on a M.2 drive with a copious quantity of free RAM.

Thank you.

[giuspen]

I will start soon the support for a third so called document type, in fact it won't be a single file anymore but structured in folders, this will better support large documents with many images/binaries

[giuspen]

Another known issue are the tables actually. If you switch between nodes that don't have tables, is it any faster?

[danieljnilson]

All of the nodes have tables. Let me do a test later where I copy a "troublesome" node (with images and tables) but remove the tables & see if that makes an improvement.

…

On Thu, Oct 27, 2022 at 2:37 PM Giuseppe Penone ***@***.***> wrote: Another known issue are the tables actually. If you switch between nodes that don't have tables, is it any faster? — Reply to this email directly, view it on GitHub <#2140 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABPRVLECMIRQCOV45N4YDQDWFLDW5ANCNFSM6AAAAAARQHSFTU> . You are receiving this because you authored the thread.Message ID: ***@***.***>

-- Daniel Nilson B.S. (Biomedical Engineering, U.C. Davis) PhD Candidate <https://www.linkedin.com/in/danielnilson/> Laboratory of Professor Steve Almo Department of Biochemistry Possibly sent from my phone, please excuse any typos.

[danieljnilson]

Howdy, I duplicated 3 nodes of varying size (in quantity of images, tables, text) but all exhibiting LENGTHY save/load times ("freezing"). I then removed all tables from them, but left the cornucopia of images. * Normally for every table, there is an image Changing between the table-free nodes and saving them was a smooth, instantaneous process. Going between a table-free node and it's "table loaded" (Table++) equivalent was interesting (ie both nodes are identical except one has tables!) * Going from *Table Free* to *Table++* was fast/seemless (no freezing) * Going from *Table++* to *Table Free* was incredibly slow, prompted a 20s freeze. I repeated the above experiment multiple times and arrived at the same result. I hope this helps!

…

[giuspen]

That's interesting, so you experienced lagging when leaving a node with tables and not when entering a node with tables. I will do some tests myself and see if I find a solution.

[giuspen]

I can reproduce the issue with large tables (e.g. 1000 cells), can you give me an idea of the number of cells in the table when you start to experience the issue?

[giuspen]

Years ago, when cherrytree was GTK2 / Python2, the tables were implemented in a simpler way, the cell edit experience was not as good as today's but on the other hand that had a very good performance on large tables.

The old days implementation was more of a spreadsheet, the current one is more like a table in a word document.

I'm starting to think I should take the old implementation back for use in large tables while smaller tables would continue to benefit with the current implementation.

[danieljnilson]

May I try isolating some slow loading pages into a separate CTB and pass it on to you? The pages won't contain anything sensitive or PPI.

…

On Sat, Nov 12, 2022, 1:50 PM Giuseppe Penone ***@***.***> wrote: Years ago, when cherrytree was GTK2 / Python2, the tables were implemented in a simpler way, the cell edit experience was not as good as today's but on the other hand that had a very good performance on large tables. The old days implementation was more of a spreadsheet, the current one is more like a table in a word document. I'm starting to think I should take the old implementation back for use in large tables while smaller tables would continue to benefit with the current implementation. — Reply to this email directly, view it on GitHub <#2140 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABPRVLDONNKSZTH3UXUTSALWH7RGFANCNFSM6AAAAAARQHSFTU> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[giuspen]

Yes please, still let me know if you have small tables (e.g. 10 cells) do you still have the issue?

[danieljnilson]

Pages with very few tables seem to load OK. My casual observation suggests the problem develops when there are many tables but i have not robustly tested this besides the experimenti described above. Usually my tables are 2x17 or around 3x10. There might be a couple 3x20s in there.

…

On Sat, Nov 12, 2022, 2:04 PM Giuseppe Penone ***@***.***> wrote: Yes please, still let me know if you have small tables (e.g. 10 cells) do you still have the issue? — Reply to this email directly, view it on GitHub <#2140 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABPRVLAUTY45MIIQAJQG2LDWH7S2JANCNFSM6AAAAAARQHSFTU> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[lbpth]

CherryTree is not slow in my opinion but I have to admit that it is not smooth, especially when we switch to other nodes or do a search. It is not slow but it is not smooth. I feel a bit laggy or delayed. Does anyone have the same experience?