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.

Reply via email to