On Tuesday, June 30, 2020 at 7:37:00 AM UTC-7, Saq Imtiaz wrote: > > A few quick observations. Note that I work on a very high end desktop that > makes it difficult to gauge performance accurately. For example, the second > Noto document from TT loads in a few seconds for me. However, comparing the > performance of Streams and Noto might be insightful. > > I need to get me one of those ;-)
What is interesting here is that Streams is much faster when the items are > collapsed. Note that streams has a lot of complexity added in the way of > filter runs for determining collapse state and drag and drag state, so I > would expect Noto to be as fast if not faster. So are the sub levels in > Noto rendered even if they are not shown? > Hidden sub-sections are hidden by reveal widgets. When I check using inspect element, I don't see the hidden text. So I assume there's no over-head. Note that the times you got for folded vs non-folded were about 5x greater. Also crucially, the editing experience in Streams seems normal, not any > slower than with just one tiddler in the stream. Even if the faster > hardware is masking some of the problem, it shows that Noto is suffering > far more of a performance hit when editing. > > I think it is important to distinguish between rendering performance, when > first opening the tiddler, versus refresh performance, when typing etc. > > > The slow performance in Noto reminds me of what happens when editing > forces a refresh of the containing tiddler or widget. This could be as > simple as a set or vars widget that is being refreshed due to a containing > tiddler being changed, which refreshes all the content inside those > widgets. One way to resolve this is to rework the logic for filters used to > avoid such a situation. > > As far as I know, nothing should be changing when typing into a tiddler. If TW is refreshing with every key stroke, then that is a problem. On Gifford #2, if you open a separate tiddler by itself, it also types slow. So even if I changed the logic to work with a temporary tiddler, it doesn't seem like there would be an improvement. My goals when making the outliner were: * Use a simple data structure (tag and list) for portability * Use only core widgets and wikitext My technique is: * Scan through the tagged list of items * Each item is either displayed or not displayed, depending on it's "hidden" status, or the "hidden" status of it's superior entries * To find the hidden status of each item, "climb" from the existing position up one position. * If the prior tiddler is a superior level, and is hidden than hide * If the prior tiddler is not a superior level, continuing climbing * Repeat until you reach superior level "1". I'm probably missing a step. But that's the overview. This backwards recursive logic is probably too much for large documents. It is possible that my two original goals are inconsistent with large-scale performance. Hmm. Now I'm thinking that I need to restructure the logic so that it runs "forward", rather than climbing backwards. Or buy a better machine. Thanks! -- You received this message because you are subscribed to the Google Groups "TiddlyWiki" group. To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/13ebd78f-36c6-4fb8-b1a0-cd208456765ao%40googlegroups.com.