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 ways. 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 *exponentially*. 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 TT -- 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/d52bab1a-a394-4b7b-8162-5c6fca15ed42o%40googlegroups.com.
