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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/tiddlywiki/13ebd78f-36c6-4fb8-b1a0-cd208456765ao%40googlegroups.com.
