Multi-threaded TiddlyWiki? Food for thought?

[TonyM]

Folks,

In my response here to a performance issue https://groups.google.com/d/msg/tiddlywiki/Y1SMtIen5ww/Nn9kggVFCAAJ

I was wondering if the fact Tiddlywiki always refreshes everything is not forcing everything through one process?

Whilst this may be needed as a rule, where has being a few question raise and refresh suppression I was wondering if there is an opportunity to allow some processes to be moved into their own thread, perhaps leaving a splash screen equivalent behind while the process runs?

Could we wrap a section of wiki text in a widget that does this, knowing full well that unless intermediate results outside the process is not a dependency, the process is independent and only rendered when complete? 

• This would allow interaction to return to the user quicker
• It provides for large dataset cases
• We could even hide the process behind a refresh button, or previous results.

Why

• This could extend tiddlywiki into larger datasets and more efficient processing, and higher interactivity.

Regards

Tones/Tony

[rdh...@gmail.com]

Hi Tony,

I had a thought about this - when I was starting out with TiddlyWiki, I would often write something like "[tag[MyTag]] [backlinks[]]" rather than "[tag[MyTag]] +[backlinks[]]" in the advanced search, which would freeze up my wiki.  I've since learned better (for the most part), but it got me thinking about running filters in an async fashion.  Here are some timings from my wiki (currently around 8700 tiddlers):

• [all[]] 2306.00ms
• [backlinks[]] with indexer 1196.00ms
• [backlinks[]] without indexer 1421496.00ms

I've had some ideas for running filters in the background, like leveraging web workers, or doing some sort of cooperative multitasking - but honestly I think it might be better just to lean into the new(er) indexing facilities TiddlyWiki has added for filters.  This would "lift all boats", so to speak, but the web workers/cooperative multitasking ideas I had have other costs such as memory usage and making filters harder to write.

Instead, I'm wondering if shifting the rendering of many tiddlers that match a filter into the background might be a useful hack in this case, and I don't think it would be too hard to do.  There could be a <$lazy-list> widget that could run a filter, store its results, and then transcludes a temporary tiddler.  In the background, a timer would take a couple results from the filter at a time and render them to the temporary tiddler, building it up dynamically.  In my experience, it's the rendering that takes up much of the time when building large lists of tiddlers like this.

-Rob

[PMario]

On Monday, September 7, 2020 at 9:04:18 PM UTC+2, rdh...@gmail.com wrote:

..

Instead, I'm wondering if shifting the rendering of many tiddlers that match a filter into the background might be a useful hack in this case, and I don't think it would be too hard to do.  There could be a <$lazy-list> widget that could run a filter, store its results, and then transcludes a temporary tiddler.  In the background, a timer would take a couple results from the filter at a time and render them to the temporary tiddler, building it up dynamically.  In my experience, it's the rendering that takes up much of the time when building large lists of tiddlers like this.

Hi Rob,

You are right. Filtering isn't the "time consuming" task. It's building and drawing the DOM. Especially if you do a

list [all[]] ... In your case it will create 8700 links, where you can only read may be 50 at the same time.

You should experiment with the tiddlywiki/dynaview plugin ... I did create a version. see attachment

IMO it will be much more effective then optimizing filters and drawing stuff that is nod visible.

-mario

[rdh...@gmail.com]

Mario -

Thanks for the tip - I'll give that a shot!

-Rob

[TonyM]

Mario

Perhaps dynaview is a partial or complete answer to this but its not really accessible to most users. Perhaps a helper method would democratise its use. Eg wrap wikitext output such that it only renders the visible.

I already have a snapshot plugin that saves the result of a complex tiddlers output, as html, and displays that rather than rendering the wiki text every time the tiddler is opened or a change causes it to be rendered again. I will share if asked. In this snapshot tool clicking it again renders the tiddler again and snapshots in agaiN, but in the mean time the user must wait. I wonder why we cant push it to the background?

If we could provide the above facility, a independant threadding  and dynaview the results i believe it could provide a perfomance improvement for larger processes and for report style tiddlers which in many way is a promise implied in the way tiddlywiki works. This would help reduce performance issues that arrise from tiddlywikis architecture when extended to larger datasets.

Further if rather than rerender a tiddler with a change detected we could simply flag that tiddler as abridged, then the user can chose to continue to view the snapshot or refresh the tiddler or a background process is triggered.

A lot of graphics bottle necks were overcome by rendering off screen before being switched into view.

Regards

Tones

[rdh...@gmail.com]

Tony -

As far as I know (and take this with a grain of salt - JavaScript is not my speciality!), the only way to background things in a page is to use something like web workers.  Web workers are completely isolated from the main page, so such a background renderer would have to either maintain a separate copy of TiddlyWiki's state (which is probably impractical at best), or use messages to communicate to get data from the main page, which is heavily asynchronous in nature and probably won't mesh well with TiddlyWiki's code, which can be very synchronous at times.

Plus, even if you built the widget tree in the background, I'm guessing that part is (fairly) cheap - I'd bet that actually creating the DOM objects and having the browser position/render them is what takes much of the time.  I know there are APIs like shadow DOM and DOM fragments to help make this faster - if TiddlyWiki doesn't already use these, perhaps they would be worth looking into!

Either way, it might not be a bad idea to use some profiling tools to see where the pain is to help guide optimization/background processing efforts.

-Rob