Performance: Open Tiddlers: Any Limits On Numbers?

Developers
#1

I have got very interested in issues to do with “how many Tiddlers can you have open?” …

My thought is to open wikis so that ALL Normal Tiddlers are displayed on load and use a live filter mechanism to hide those not of interest (along the lines of how @BurningTreeC does it in MCL “live column reductive search”) via user input search/filter (they still there, but hidden).

I am not asking here about numbers of Tiddlers in a wiki.
Rather seeking your thoughts on the number of open Tiddlers (that would be sensibly possible).

For instance is 800 open Tiddlers viable? (just an arbitrary number)

Any thoughts welcomed.
TT

#2

I have not tried opening hundreds of tiddlers at once but I have some experience with how TW works under the hood. I see two possible issues with this approach:

  1. While modern browsers are very fancy, all of that DOM (HTML structure) information has to be stored somewhere and sifted through when things happen. With most elements being invisible I don’t think it’d be that much of a big deal, but keep in mind that having a few hundred fairly complex entities on the page, even if invisible, could potentially cause slowdown when DOM is mutated (that is anything changes on the page).
  2. Tiddlywiki rendering works by creating objects that match what you see on the screen and having them listen to changes. This can end up being dozens of nested objects in a simple tiddler (just the UI) and hundreds (or even thousands, see below) in one with a fair bit of content. Every time you make a change to a tiddler, TW will ask each of those objects if they need to be updated. With hundreds of open tiddlers this can result in tens of thousands of events to check. You can probably expect delays of at least ~100ms per tiddler change, much more depending on your circumstances. (technically

And your circumstances might include having a gigantic table with few hundreds of rows and nested lists, which you use to track which LEGO bricks you’re still missing in the old LEGO sets you’re trying to complete. Thankfully TW seems to be very clever about when it has to rerender a whole thing like that, but if you happen to have a lot of tiddlers with a lot of broad lists doing even simple things, the stacking will be unforgiving.

So I decided to test it. I opened 430 tiddlers on https://tiddlywiki.com, I did so running this script in the developer console after unfolding a bunch of menus on the right:

for (const i of document.querySelectorAll('.tc-tiddlylink')) {
    i.click()
}

And some rough timings:

  • Clicking Edit on a page - ~1.5s
  • Waiting for draft to update after making any changes - ~0.5s
  • Saving changes to a page - ~1.0s
  • General interaction - a noticeable slowdown, probably something in the lines of 0.1ms

Is it usable? Yes
Would I use it? No, unless I was paid to do so

1 Like
#3

@Maurycy … Is right. Most of the content will be invisible and it doesn’t make much sense to refresh it if it isn’t shown.

As mentioned in the other post the dynaview plugin may help here.

You can open the demo page which has 810 tiddlers open in the story river. see: https://tiddlywiki.com/plugins/tiddlywiki/dynaview/

It only renders some of the tiddlers as shown in the sidebar. You can run your tests there. I think there is no real slowdown. … BUT if you scroll very fast, you may see the refresh. … Depending on how fast your computer is.

#4

I did test it with my mobile. There you can see the refresh from time to time, if you scroll very fast and the browser uses the momentum. I was able to scroll 140 tiddlers in the river with 1 swipe and saw about 10 “fly by” updates :wink:

#5

Thankyou for the reply and the effort you went to test it out. Very helpful!

Grazie
TT

#6

Thanks @pmario for understanding my query.

In the back of my mind is the idea to be able open a TW with all normal Tiddlers open and simply filter out what you don’t need to currently see.

My question is, as both your and @Maurycy’s excellent responses illustrate, is not so much about TW as about the limits of browsers.

Actually that is good to know, explicitly!

I will do some tests.

Tx, TT

#7

I did think about this too and did create a prototype of a story editor plugin, which is alpha quality, because the workflow is way to complicated to be useful.

It adds a “save story” button at the end of the “Resent tab”, which makes it easy to create a new story. Eg: my-stroy

If the “Recent” tab is used it will create a config tiddler and store the order in the my-story – list field

The cool thing now is, that you can create a new configuration that uses a filter-field.
Eg: reverse-story with a filter: [enlist{my-story!!list}reverse[]]

Including the possibility to drag and drop sort lists that contain filter-strings, which isn’t possible with TW atm.

I think a system like this would be more efficient that opening 800 tiddlers and then apply a search.

#8

I don’t know what BTC does but a very cool thing with all tiddlers open and filtering out tiddlers by purely using CSS is that you can have a static TW where you seemingly open and close tiddlers!

#9

Right.

I am often confused on this kind of issue. Your comments helped me get a bit clearer. But I got a little way to go yet. :slight_smile: Tx, TT