Help with performance debugging

[Bob_Jansen]

With my gun wiki, I have uploaded 152 guns from South Australia and now am noticing a slow response time showing the first gun I click on. Once the first gun has been displayed, subsequent displays work satisfactorily. The issue exists whether loading from a local copy or a server copy (Memorial Guns Australia — © Royal Australian Artillery History Company, 2025). Let the wiki load, then open the South Australian toc entry and click on one of the links.

I have looked at Firefox’s developer tools and it reports a ‘JANK Error’ which according to the description indicates a performance issue of 5 seconds that may be worth investigating. The time of 5 seconds seems about right for the delay in displaying the first gun entry.

I know nothing about TW’s technical internals and so am in the hands of the technical team with this. If you need an editable copy of the wiki, click this link wiki in dropbox

I attach copy of the developer tools window if anyone knows what all this means.

All advice and guidance appreciated.

bobj

[Bob_Jansen]

Sorry people, uploaded the wrong screengrabs and do not have access to my computer tonite. Will upload tomorrow. However, the problem area DuckDuckGo identified was a timer in the loading process.

Bobj

[TW_Tones]

Bob, to my knowledge there is not timer applied to a standard empty wiki, have you installed any plugins with a delay or saver timer etc…?

I believe the word jank may refer to Janky, which just means suboptimal. It clearly seems to be when accessing a file:// address which may refer to your local machine, and here I see to a subfolder that is also synced with dropbox. As a result is it accessing an external resource like an image? It seems that a direct to dropbox file reference could add a lay of complexity, such as if a local copy is not present it (the file system) would go to the dropbox server even if only to check its current.

[Edited] I see now that you are relying on Geocities, which could be part of the delay on your first external image.

I found the above link load much quicker than I expected including having an unreliable internet link here.

I see the delay you spoke of but don’t have sufficient access with your UI impediments in place (not yet hacked it) to look more closely eg edit the tiddler, review plugins and search JS.

The link on the tiddler I tried is https://cultconv.neocities.org/ArtilleryRegister/ArtilleryRegisterPilot20260206_SA#MGA0612644_LandingPage but the address bar shows only https://cultconv.neocities.org/ArtilleryRegister/ArtilleryRegisterPilot20260206_SA

There is a message There are no links to this record but I presume this is no backlinks internally.

[Bob_Jansen]

@TW_Tones , the issue is not related to neocities nor Dropbox because the delay is present when loading from local file store as well as from the server. My only thought after pondering the issue for some hours is the mapping plugin and tomorrow, my first task will be to remove that plugin. I have been concerned about this plugin in any case as i wonder what its performance would be wit many tiddlers having the geomap tag and this being scanned to extract longitude and latitude information. I have been arguing for the use of a static map for the gun’s location as they are not very ‘active’

Also, the issue is not the initial load of the wiki but the rendering of the first gun tiddler from the South Australian set. After the first, subsequent renderings of other gun tiddlers is ok.

Bobj

[Xyvir]

One thing to lookout for is overuse of regex matching in a plugin.

While extending the TiddlyStudy edition I had to remove it’s ‘Freelink’ footer backlink pill detection as it was actually running regex matching every Tiddler Title against every Tiddler Body on every keystroke.

Using the native Tiddlywiki Filters is much more performant as my understand is it runs of a small cache/index instead of just manually matching all tiddlers all the time.

-Xyvir

[Bob_Jansen]

@Xyvir you may be on to something. I’ll try deleting all backlinks calls and see if that makes a difference.

Bobj

[Xyvir]

The way I narrowed it down is I just started disabling plugins one at a time until performance improved. (making sure to re-enable the last checked plugin)

Then I could start ‘masking’ the plugins ‘content’ tiddlers with blank ones to try to narrow it down further.

With a bit of patience you can sometimes figure out experimentally where the issue lies.

-Xyvir

[Bob_Jansen]

After much more testing in varying configurations, turning plugins off, etc, I am closing in on the culprit - the geospatial plugin in.

With no network connection, the Start page does not load the map of Australia with the three geomarkers highlighted (there are only three guns with the geomarker tag left over from earlier testing). However, and I can’t explain why, the first gun entry loads with no real delay. I can not explain why as those guns do not have the geomarker tag and so should not be activating the geospatial plugin at all.

Anyway, activating the network, the delay on the first gun display returns, not the start page though.

As for timers, the one that seems to be constantly highlighted is in the $:/core/modules/utils/utils.js script, as shown below. This section of script is continually highlighted by the debugger tools.

So, thanks for all the pointers and thoughts. A re-consideration of the geospatial side of the interface would seem to be prudent.

bobj

[etardiff]

@Bob_Jansen, I’d generally suggest installing the Advanced Performance plugin to investigate performance issues; it’s likely to give you more actionable information than your browser debugger. (Note that you’ll have to save and reload your wiki after installing, and again after enabling the Performance Instrumention setting in Control Panel > Settings > TiddlyWiki.)

To use Advanced Performance, just click around in your wiki to establish a pattern of “baseline” use, then try loading any tiddlers where you’ve observed slowdown. In this case, the only tiddler that appeared by default was “Memorial Guns in Australia” (no noticeable lag on my machine)… but navigating to “Australian Capital Territory : Campbell - Colonial 64-Pounder Anti-ship Cannons” via your TOC did produce several seconds of lag.

I then clicked on “Show details” in the Advanced Performance footer and navigated to the “total longest” tab. You may be interested in any/all of the tab reports, as it’s useful to consider both which filters are more time-intensive and how often they’re actually run, but I generally find “total longest” is a good place to start.

This indicated that — as you suspected — your use of backlinks[] is likely to be the culprit. This is consistent with your observation that the first “content” tiddler is much slower to load than subsequent tiddlers: once the wiki has constructed a temporary backlinks index, subsequent uses of the backlinks operator will be much faster.

Once I’ve identified a filter that may need refinement, I paste that filter (or a segment thereof) into Advanced Search to find the source tiddler(s). In this case, that led me to $:/TLS/Procedures. As an experiment, I removed the procedure that used [all[current]backlinks[]], reloaded the wiki, and noticed an immediate performance improvement. So if this were my own wiki, I would now be reconsidering whether a) I can remove this expensive macro from my ViewTemplates, and b) if not, whether I can move it someplace where it won’t need to run on initial tiddler load — say, behind a $reveal triggered by $button interaction, or inside a tab that’s not loaded by default.

Once you’ve successfully diagnosed an issue, you can remove the Advanced Performance plugin — or just uncheck the “performance instrumentation” setting, so the plugin remains available but unobtrusive for users who don’t know to look for it.

Hope this helps!

[Bob_Jansen]

Thank you @etardiff . I have downloaded the plugin and will play around with it.

bobj

[Bob_Jansen]

Thanks to all who provided feedback and advice, especially @etardiff whose link to the Advanced Performance plugin was invaluable. Normal service has been resumed.

bobj