Relink Plugin Performance

[History Buff]

All,

I apologize if this has been addressed before. I did some searching and didn't really find anything.

I have a rather large wiki with 3370 tidders, uses 244 tags and is nearly 11 MB in size. I've noticed a huge slowness when I rename a tiddler. It takes 1-2 seconds for relink to finish finding all of the tiddlers that are going to be affected. I'm not exactly sure when this started since I don't rename tiddlers very often, but it seemed to just suddenly start being an issue and not something that just got slower over time (appearances can be deceiving so I could be wrong).

I've played with the configuration options a bit, but haven't found anything that really makes a difference. (I must admit that I don't claim to understand the many options fully.)

Since I don't rename tiddlers terribly often, it's more of an annoyance than a real issue. 

Is this just a side effect of my wiki being large? Are there some options that would affect performance more than others?

Thanks in advance.

[History Buff]

One more thing to add. I've also noticed that while I'm editing the tiddler than I'm changing the name of, performance is generally sluggish throughout. This is especially true if I switch tiddlers before saving or try to add or edit a field. It's not until I save the tiddler that performance goes back to normal.

[Charlie Veniot]

Silly questions: what version of TiddlyWiki and what version of Relink?

Also, if you disable Relink, do you notice a significant difference in performance changing a tiddler's title, compared to doing same title change to same tiddler with Relink enabled ?

[History Buff]

Not silly questions at all. I'm using 5.1.23 for Tiddlywiki and 2.0.0 of Relink. 

I hadn't tried disabling or deleting before you asked. I did try both methods and changed the name of a tiddler. While there was still some delay while Tiddlywiki determines which other tiddlers, the performance was greatly improved. It took maybe a few tenths of a second for TW to find all the affected tiddlers.

[History Buff]

One further question that I just thought of. I have several iFrames linked to Wikipedia pages within the TW. Would that happen to have any performance issues with Relink or Tiddlywiki in general?

[History Buff]

So I decided to enable performance instrumentation to get a feel for what was going on. When I did this and started changing a tiddler title the mainrefresh was only 364 ms. But when I exectuted $tw.perf.log(); to see what the filter performance was, the first filter listed which was "filter: [title<fromTitle>backlinks[]limit[1]]" and the timing was 3085.2 ms. That's definitely noticeable and was about 85% of the total time. 

I also noticed that if I just sit there and wait several seconds, the delay in switching tiddlers and editing fields goes way down.

[Charlie Veniot]

Without having experienced your issues with TiddlyWiki performance (I don't have any TiddlyWiki as big, and I likely haven't installed as many plugin's), I might not be of any use to you other than cheering you on with the kind of fine sleuthing you are doing.  Especially if you note your findings here: that's a gift for the rest of us!

So I've got my pom-pom's out for you.

Maybe some more experienced folk can chime in with ideas?  

[History Buff]

Alright, a little more information.  I just did a different test with backlinks. On most of my tiddlers, I have a tab that lists all of the backlinks to that tiddler. When I click on that, I see a similar delay. Looking at the performance instrumentation, I see the following:

mainRefresh: 3381.10ms

"filter: [all[current]backlinks[]!search:description[Newspapers]limit[1]]" takes 3316.5ms

However, this long time only happens the very first time I click this particular backlinks tab for any tiddler. Any other tiddler after that, I can open that tab in a fairly fast time. Although, I need to experiment a bit further, I think this is the same thing that is happening with Relink. It's the first time a backlinks filter is run that takes forever. Any time after that, it seems reasonably fast (unless the TW is reloaded then it starts all over again). 

So my question is now becoming what is it about the first time the filter for backlinks is run that takes so long? Is it the size of my TW or something else? 

[History Buff]

Thanks for the encouragement!

[Charlie Veniot]

Hey, when I see somebody doing some serious sleuthing, it isn't so much technical skills that get my attention.  It is the creativity and inquisitiveness in action (i.e. the "what happens if I do this or that, or turn this on, or turn this off... ), that is really good stuff.

[PMario]

On Sunday, June 6, 2021 at 11:53:59 PM UTC+2 History Buff wrote:

One further question that I just thought of. I have several iFrames linked to Wikipedia pages within the TW. Would that happen to have any performance issues with Relink or Tiddlywiki in general?

No, It shouldn't have any influence on performance.

-m

[PMario]

On Monday, June 7, 2021 at 1:35:57 AM UTC+2 History Buff wrote:

 

So my question is now becoming what is it about the first time the filter for backlinks is run that takes so long? Is it the size of my TW or something else? 

Calculating backlinks is a CPU heavy function, that's why there is a "baclinks-index" in the core, which is cached. So he first time your

tab is shown, the index needs to be built. Every other time it can use the index, which is significantly faster. The index isn't saved, that's why it has to be calculated after a page refresh.

-mario

[Damon Pritchett]

Thanks. That explains it. I’m assuming that’s why Relink performs similarly since it’s has to calculate backlinks. Would that be a correct assumption?

--
You received this message because you are subscribed to a topic in the Google Groups "TiddlyWiki" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/tiddlywiki/tsciD8BLfTE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to tiddlywiki+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/4f639434-b089-4c39-9c1b-89bb4e71da40n%40googlegroups.com.

[PMario]

On Monday, June 7, 2021 at 6:26:01 AM UTC+2 History Buff wrote:

Thanks. That explains it. I’m assuming that’s why Relink performs similarly since it’s has to calculate backlinks. Would that be a correct assumption?

Yes, It's not only backlinks. The relink plugin does a lot more checks, if you change the tiddler title. ... It checks all the tags-fields in all tiddlers. It checks all the list-fields and then it checks all the texts, if there are macros, widgets and so on using this tiddler as a parameter. .. So there is a lot of work to do.

If you change the title of a tiddler, the relink-mechanism is activated. It creates the "The following tiddlers will be updated" "dropdown" element. ... If you don't save the tiddler, this list will probably be recalculated with every edit key-stroke .

So if you change the title, it may be best to save the tiddler and then edit the text afterwards if needed.

-mario

[Flibbles]

I don't know of a way to get Google to tell me when conversations come up concerning Relink, so I'm always late to the party.

PMario is right. Relink has to scrutinize every tiddler when it looks for relinking, but it does have an indexer, and that indexer tries to reduce the need for a "full tiddlywiki check" as much as possible.

• The first rename you make after loading your tiddlywiki will take a while. All the subsequent ones will be much quicker, since it will have a shortlist of which tiddlers are relevant.
• The first keystroke you make when typing in a new title (or looking at the Relink References tab) will also cause a delay. This too is cached, so it should only happen once per browser tab (or once per $:/tags/Macro change).

Hope this helps! You aren't completely wrong that Relink might seem slower in certain respects in V2. I had to scrap a ton of old optimizations I had, but I got the indexing working as best I could to compensate.

-Flibbles