Ciao Mark & Saq

Though  I don't grasp coding complexities  I can comment from observation 

> On Tuesday, June 30, 2020 at 7:37:00 AM UTC-7, Saq Imtiaz wrote:
>> 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. 
On Tuesday, 30 June 2020 17:20:13 UTC+2, Mark S. wrote: 

> 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.

Right. *Everything* is slow. Actual edit, either in Noto instance or to the 
same Tiddler separately whilst Noto is open seem much the same. Actual edit 
is slowed but its when *saving the open instance* in Noto or *changing 
folding* it gets really slowed (the list field update and hiding level 
setting? Yes?) Beyond a certain point the browser freezes for me.

On initial loading, BTW, opening the Same Tiddlers without Noto using just 
the $:/StoryList is much the same as a Noto instance. Load is same. Edit is 
much quicker.

My goals when making the outliner were:
>   * Use a simple data structure (tag and list) for portability
>   * Use only core widgets and wikitext

Right. From my point of view its a nice approach. Why? Because with careful 
"stem name choice" you can have human readable titling you can use many 
That matters for many of my cases. For instance its a snap in Noto to sling 
in a chapter of a novel and get correctly numbered paragraphs that directly
correspond to source material ... so ... titling

"GE Chapter IV" is split to ...

"GE Chapter IV 1" thru to "GE Chapter IV 49"

Each number being a paragraph number.

‚ÄčThat seems very viable so long as your Noto instances are not holding 
zillions of items.

In a previous example I gave of a 105 page (105 Tiddler)‚Äč full length 
screenplay the (in non Outliner) very worked well. 
I think the Outliner would manage just as well at that number of items too.

The Gifford-Test-2 was interesting because performance at First was fine. 
But as absolute numbers increased so performance started dropping 

To me that means Noto is currently best with projects whose total number of 
"chunks" per Noto instance doesn't get too high.
In practice I'm confident I can use it to deal with books by having an 
instance per chapter and so on. Sensible chunking.

David Gifford's list is challenging as I can't really see a way to chunk it 
down. If you chunked to sections, Noto each, its kinda defeating the 
objective of an umbrella outliner.

FWIW, the eBook edition of TW uses "strategic chunking" I think. I think 
that is one of the reasons it appears performative.

... 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.

IMO, for actual things I make, I think it will often be fine as it is. And 
large stuff needs thinking about anyway according to the specific logic of 
the media concerned.

It would be great if Noto performance could be improved with higher 
numbers, but, for me its basic logic is very neat, useable & human readable 
with a big range of uses.

Best wishes


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 view this discussion on the web visit

Reply via email to