Lazy-all performance

Developers
,
#1

What performance should I expect for a tiddler to load from skeleton to full tiddler?

In my current setup I have monthly toc’s that list daily tiddlers within the month, and there is a significant delay on loading the daily tiddler when clicked. However if I post a permalink to the same tiddler, it loads immediately.

Daily tiddlers range from 500kb to 750kb in size.

#2

I am not sure what you mean by skeleton".

From past experience it should not add noticeable time. Is the permalink to the tiddler in the full wiki or a static representation?

Performance improvement’s can often be found but it is multi-factor so access to an example wiki is helpful. Can you make the problem occur on TiddlyWiki.com or a copy of it? then we can try it.

#3

Sorry I should have said “skinny” version, not skeleton version.
Lazy Load Mechanism

The permalink is to a tiddler in the full wiki.

<flux.wvwlogs.com> is an example of one of the wikis in lazy-all mode. Patience required, the tiddlers will load…

and a permalink as well: https://flux.wvwlogs.com/#20221202-WvW-Log-Review

#4

Ah Ha,

Caveat: I do not use skinny tiddlers, but have a theoretical understanding.

  • It would help if you added a splash screen for any Wiki that may load slowly even for people with slow links. see Creating a splash screen
  • Second, the advantage of skinny tiddlers is when you only “load on demand”. They would all take time to load. However having skinny tiddlers that always load when you arrive at the site “defeats their purpose”. By definition they should only load after the core and non-skinny tiddlers load.
  • Perhaps the common tiddlers and default/at startup tiddlers should not be skinny tiddlers?

On a related note we recently discussed;

Others may help more if you detail your host server details.

[edited] Post Script: If the tiddler you display is a compound tiddler drawing on many other tiddlers to generate its content, it may need to load all related skinny tiddlers and again the value of skinny tiddlers is less. Either,

  • Don’t use skinny tiddlers, and let the whole wiki load, it will possibly be faster especially if you reassure them with a splash screen.
  • And/Or generate a snapshot or static tiddler which is a non interactive copy to deploy at load.
    • I went to try and install my tiddler snapshot tool but got an error trying to make the import button visible.
#5

It seems there is something loaded as a raw-markup library. I did open the browser dev-tools and this library did throw errors.

Did you try it without this library. Especially this comment would worry me. If a library has this type of comment I’d not use it.

// sort is super fast, even with huge tables, so that is probably not the issue
// Not solved with documentFragment, same issue... :(
// My guess is that it is simply too much to hold in memory, since
// it freezes even before sortable is called if the table is too big in index.html
#6

That would be the sortable.js I added based on a thread here. It did not impacted stand alone wikis served on tiddlyhost. I’ll remove it and see how it performs.

#7

The wiki is currently 70Mbs uncompressed and would be larger if not pruned. As data ages it becomes less relevant until a new patch releases, then everyone wants to compare prior periods to current. I thought switching to a nodejs version with lazy-all would provide ability to maintain all the data in separate tiddlers and push only when needed, thus reducing the bandwidth on each serve.

This would be due to the credentials required, the server restricts you to reader only.

1 Like
#8

I think going with skinny tiddlers for a wiki like that is the right way to go. …

I thin I did spot something. …

The permalink you gave us is loaded immediately, because it points to a skinny tiddler. When TW sees it, it knows to show the text content. … So it loads the body and shows it. Flux Capacity — WVW Log Review

The Network dev-tools say it’s about 400 kByte . That’s reasonably fast (for me). …

When I click a filter on that tiddler content is loaded on demand, as expected eg: lots of icons.

then ---------------

I close this tiddler. It seems the background shows an overview of the last 8 days. … Which then seems to request all that info. … with the next 1 minute default poll … that seems to be OK

BUT ---------------

if I open a new tiddler from the sidebar it opens the skinny tiddler … and also waits until the next 1 minute tick comes up.

So worst case users have to wait 1 minute … Best case 1 second … It depends, when the timeout is over.

So the question is: Do you “block” the request for the tiddler content by accident or by intention.

My guess. It’s an accident … may be a timeout setting somewhere.

I don’t use lazy loading, so I don’t know all the options that are possible.

So “lazy loading users” are requested here.

-mario

#9

by accident, I’m doing good to get the nodejs version up and serving in lazy-all mode. Learning as I go.

This is a function of the Mono theme tweaks “Use timeline grid when story river is empty (grid preview of 10 recent dates for modified tiddlers)”

I’ll turn that off and see if it changes anything.

#10

I wouldn’t turn it off. … Most of the time, when usrers close everything, they are searching in the sidebar. So the attention is at the sidebar. So imo it’s good, if the wiki would load the last 10 results. …

I actually did like that feature. …

#11

I think it’s not a performance problem. At least not with my internet connection. IMO it’s a timing problem. So we need to find out, what causes the delay if a still skinny-tiddler is selected from the sidebar.

#12

I turned off the mono tweak timeline grid and things are working much faster

#13

Well, maybe i spoke to soon. when i tested on laptop i got the same delay problem.

#14

Yea, I was testing it too and also made an unlucky hit. It needed about 30 seconds. So it still depends on the timeout. …

I did debug the source code and there seems to be a problem. … But I’m not 100% sure, because I don’t know that code very well. … I’ll create a GitHub issue. … I’ll post a link when that’s done.

1 Like
#15

The issue is at: [BUG] Lazy-loading seems to wait for the 1 minute timeout when tiddler is shown in story-river · Issue #7138 · Jermolene/TiddlyWiki5 · GitHub

So we’ll need to wait a bit. @john.edw_gmail.com … It would be good if you wouldn’t mess with the system at the moment. I think as it is it’s OK to test it.

#16

Leaving it be, I’ll work on another subdomain.

#17
  • yes skinny or lazy tiddlers make a lot of sense just not on the tiddlers that load and are needed initially.
  • One way it to display a tiddler that does not need to get information from multiple tiddlers, one way is to display a snapshot of a tiddler captured before the last save.

I knew I could not save, I just thought I could test it in memory.

Perhaps experiment with the following;
Here is the package which still seems to work in the latest version. Install then click the camera Icon snapshot.json (6.2 KB) no reload needed.

  • This generates a tiddler $:/snapshot/tiddlername which is a rendered copy of the tiddler and displays the rendered version instead.
  • It captures the result and hides the normal display behind the fold.
  • The advantage is when first loaded the saved result is displayed and access to all related tiddlers not needed.

It may prove of use.

#18

@john.edw_gmail.com … Have a look at [BUG] Lazy-loading seems to wait for the 1 minute timeout when tiddler is shown in story-river · Issue #7138 · Jermolene/TiddlyWiki5 · GitHub

It seems Jeremy has fixed the problem with that commit. You’d need to run your server with the latest master-branch to test this. … If your server, with the links you provided, is a production server, you should first test it on a test-system.

If there are some more questions, just let us know. May be GitHub [BUG] Lazy-loading seems to wait for the 1 minute timeout when tiddler is shown in story-river · Issue #7138 · Jermolene/TiddlyWiki5 · GitHub may be a better place to discuss technical details.

#19

Thanks @pmario! I have a stupid question, on how to proceed. If I installed globally via npm package, can i just reinstall direct from the master without messing up future npm package installs?

npm install https://github.com/Jermolene/TiddlyWiki5.git

Thankfully, I have been keeping the tiddlyhost version and an offline version since you said to leave the other configuration alone. I have added new tiddlers for summaries and echarts but they are backed up.

#20

You can use/modify your online version again. We don’t need it anymore for testing.

I personally use the development version as my global version.

I do use IIS with a Node.js setup but it uses a local install. So I can’t mess it up accidentally.

I think it would be the best way to create a new server configuration with the existing installation. Then cd into the new directory and install TW from GitHub locally into that dir. As you suggested. Then you should be able to start from that dir with the latest master. … For testing the fix.