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.

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 

Reply via email to