V5.4.0 prerelease - Performance Regression Using List Filters in ViewTemplate

Developers
#1

I use headers tagged $:/tags/ViewTemplate which make liberal use of $list filters.

These headers now result in steadily increasing delay as more tiddlers using them are opened in 5.4.0. Some degree of delay has always occurred in this case, but the cumulative effect is much more prominent now.

While trying to isolate the issue, I noticed that a filter run with extra steps makes the most dramatic difference. Is this due to additional parsing that is required by new filter features? I strictly use zoomin view; would an eventual “true single tiddler mode” be my saving grace for this use case?

FilterPerformance
FilterPerformance1500Ă—855 57.6 KB

Your help is needed to test v5.4.0
#2

I cannot think of anything off the top of my head that would explain the performance difference you are seeing. Are you able to share a wiki that shows this behaviour? or replcate the problem on tiddlywiki.com? Thank you.

Has anyone else noticed any performance issues compared to v5.3.8?

#3

Sure, I’ll give it a shot within the next couple days.

1 Like
#4

Gave myself extra time in case I ran into trouble :sweat_smile:

Not sure how to upload the TW, so this is the list of tiddlers for import:
FilterPerformance.json (22.2 KB)

I made the following configuration changes to the empty.html:

  • Added Test1-Test150 to “Default tiddlers” list
  • Zoomin view, animation duration 0

Delay goes from 130ms to about 700ms in 5.4.0 when clicking around the test tiddlers in the sidebar’s “Open” list. The header is titled “Header” and filters 50 tiddlers with the prefix “FFF_” (x10 so delay is apparent).

1 Like
#5

Thank you @diligent_path

Could be so kind as to try this copy of empty.html to check if it resolves the problem:

There were some changes to the sort operator that might be responsible for the poorer performance which have been reverted in this file.

#6

Related GH PR: https://github.com/TiddlyWiki/TiddlyWiki5/pull/9702

#7

Definitely much better! Not to split hairs, but just in case it changes the scope of the issue, it’s averaging around 240ms vs. 150ms on 1.3.8 with the sample tiddlers. Certainly much faster though, and perhaps negligible in the long run. Thank you!

#8

@diligent_path thank you for the feedback.

It is likely worth investigating further to determine the cause of the remaining performance difference.

#9

Could you please be so kind as to compare the new copy of empty.html that I linked above to v5.3.8 one more time please?

I am getting consistent average times for this filter on both of them of around 130ms:
[has:field[CCC]!prefix[DDD]!sort[EEE]]

Use a new profile on your browser and closes and re-open it before each test please.

If you still find a difference is it in the timing of the filters, or mainRefresh, or elsewhere?

#10

Ah, I had been testing in TiddlyDesktop. The mainRefresh was +40ms vs. 5.3.8, but also lagged by an additional 100ms about 1/3 of the time.

I tested on a clean install of Chrome on a secondary machine and the 100ms lag is gone. I’m still seeing a ~35ms difference (95 vs. 130), but I doubt I would ever notice this under normal conditions. This is all in reference to mainRefresh.

1 Like
#11

I think 30 to 40ms differences is in the range of browser internal optimisations, that are on and off between different interactions.