search

zadam / trilium

Build your personal knowledge base with Trilium Notes
GNU Affero General Public License v3.0
27.2k stars 1.9k forks source link

Editor slows down when many nodes are expanded in tree #1192

Closed bhank closed 2 years ago

bhank commented 4 years ago

When many nodes are expanded in the tree, the editor is less responsive.

I can replicate this by expanding a lot of items. With about 1650 items expanded in the tree (an estimate based on Dev Tools reporting a height of 30px for one item, and 49591px for the topmost ul element in the tree), if I hold down the "x" key in the editor for 10 seconds, only one or two x characters appear right away; four seconds after I release the key, 289 more x characters appear all at once.

If I click the "Collapse note tree" button, the slowness disappears; holding down "x" for 10 seconds results in a smooth stream of x characters appearing.

I ran into this in normal use because I have a lot of notes and I'm not in the habit of ever collapsing the tree; after enough days of use, many nodes are expanded. Typing would get painfully slow, and frequently the frontend would reload. It was getting to the point of unusability, but now that I know it's related to the tree, at least I have a workaround.

I tested with the latest release, 0.43.3, on Windows 10; log file attached (although I don't think it contains anything interesting).

trilium-2020-08-15.log

zadam commented 4 years ago

Hi, thanks for reporting this issue.

I managed to reproduce this and analyze a little bit - it's caused by "forced reflow" - editing the text forces the whole layout to be recalculated which gets slower with the larger amount of elements (caused by expanded tree).

There's a CSS property contain which mitigates this by hinting to a browser which elements are sort of isolated and changes within do not need to propagate out (and the other way round). Quick experiment showed that it does help and editing gets fast again, but it had some visual side effect so I need to look into this more.

zadam commented 4 years ago

Hi, although I managed to solve the responsivity of the editor, the huge tree itself is still quite slow.

What you said about never closing notes resonated with me - I have a similar usage pattern and I usually just end up with huge half expanded tree. But this huge tree is then also difficult to navigate and I usually need to click on "collapse all" to be able to navigate myself around the tree again. So huge trees are not just slow, they are also difficult to use.

As a mitigation I'm thinking about "auto collapsing" - that nodes would automatically collapse after a period of inactivity (and if they are not opened in any of the tabs).

zDEFz commented 3 years ago

Can reproduce. MacOS, Trillium-Notes Version 0.45.2 Can circumvent by making subs. Would it help to cache more in RAM? Trillium-Notes only taking around 1GB on my machine, but having a lot RAM left.

zadam commented 3 years ago

No, I believe it's just too much being rendered in browser which makes it slow. FancyTree (library for tree display) could theoretically display only notes currently in display, but I don't think it has this optimization ...