Advanced Performance plugin 1.1.0 - Expanded performance instrumentation

Plugins
, , ,
#20

@Yaisog Thanks, that was actually unrelated to what I had in mind. I completely missed the fact that the duration for other refresh is calculated from the filters duration itself, which caused subfilters to be double (or triple or more) counted.

Version 1.1.4 is out with the following changes:

  • other refresh now correctly ignores subfilters when calculating its duration
  • Tabs ‘‘Median’’ and ‘‘Average’’ now display subfilters just like other tabs do

I also included your example in the plugin’s test cases – I’d like to add a small “(Thanks to XYZ for providing this example)” with a link, if you’d be kind enough to tell me what name to use and what to link to.

1 Like
#21

You can use Yaisog Bonegnasher (https://github.com/yaisog), unless you prefer clear names… :wink:

#22

@Maurycy

Feedback:

  1. READABILITY: Some of the background text is hard to read.

  2. READABILITY again: If all timings are presented in milliseconds, say that somewhere in the text. That will allow you to reduce the “noise” in the presentation of the results data.

Other than that, what a fabulous plugin – I’m only discovering it now 13 months after initial release!

:trophy:

#23

Re 1 - Huh, I don’t remember that gray being this unreadable. I’ll have to do something about it.

Re2 - I am not convinced. I a ma big fan of showing units for semantic clarity even if it ends up in a slight visual clutter :). I can concede to make the units a slightly different color so that they are easier to filter out visually!

#24

Fair.

However, let me tender this: When there a myriad identical units on display, it imparts no more useful information than to say it once, perhaps prominently, somewhere else. When there are many different units in play, I’m in total agreement with you.

I have some considerable experience in this area (in my day job, ~30 years in lab and pharmaceutical software), 200 or more copies of ms is just noise.

Persuaded?

#25

I am afraid not. I tried to see how it looks without ms all over the place and while it’s neater I find it less readable. I suppose part of the problem might be that I don’t have extensive experience reading sheets of data and as such don’t have the instinctive ability to memorize column units. Maybe it was because I was just browsing the table without actually doing any performance analysis and was reading the data differently. Maybe it’s just me being odd.

For now I’ll err on the first case – most users are not going to have extensive experience and as such they might find things readable as they are now. Ultimately it’s not that big of a deal either.

At some point in the future I’ll add an option to just show/hide the unit next to the value. For now:

Version 1.1.5 is out – it mostly concerns styling and colors to make things more readable. It also makes the table wider to use up the space more effectively, since long filters are pretty much a norm.

#26

Version 1.1.6 is out which makes the problem a moot point. Settings tab was added for the plugin and you can customize whether the unit suffixes appear or not.

#27

Glad my speedometer doesn’t work like that. You?

:sunglasses:

#28

Hi, Maurycy I have TW5 with 21K tiddlers
https://heeg.ru/shop2_4.html?id=10qKIul6mb6O0QCIHjWVHf_4WRhzLDj-pQ5tPPIp0BjM#index
How can I improve its performance with your plugin?

#29

You can use it to get a better view at what’s happening behind the scenes in your wiki and hopefully use that information to optimize things. There is no one-size-fits-all approach here, what I’d do if I had a slow wiki would be as follows:

  • Install the plugin
  • Enable the advanced instrumentation
  • Save and reload the page (required to new JS code to be hooked up on startup)
  • Perform some actions I know are slow
  • Click “Show Details” in the bottom bar
  • Use the tabs to see what filters are taking a lot of time to run. Might be a good idea to start with “Single longest” and see what’s the filter at the top. But maybe the problem is a fast filter that’s executed thousands of times, so “Most used filters” will be helpful here.
  • See if you can rewrite the slow filters in such a way that they are faster, or rewrite filters that are used excessively to be used fewer times.

It boils down to understanding how TW render loop works under the hood. Whenever any tiddlers is changed, a UI refresh is scheduled. During UI refresh the code goes through the whole tree structure of Tiddlywiki widgets asking every filter to refresh itself as necessary – so every filter will be executed and the new results will be compared with the old results, if they are different something is bound to change. That something can be as simple as updating text or as complicated as replacing the entire contents of a <$list> widget.

With that you can see the performance of your wiki is proportional to A) how many tiddlers are open at once; and B) how complicated the wikitext in them is. Thus, to improve performance either of the above has to be simplified.

I don’t understand what your goal here is.

#30

Thank you! Your plugin found, that my filter [all[current]tagging[]tag[$:/TOC]limit[1]] total time 7980.60 ms (on open) I try to change it to [is[current]tagging[]tag[$:/TOC]nth[1]]
but it has the same time result. How can I change it to improve performance?

#31

I wish I could help more but I am afraid I don’t have the time to dig deep. tagging[] on its own should be fairly fast, since it uses indexes, the issue might be the number of times the filter runs, but beyond that someone else might be able top help more.

1 Like
#32

[tag{!!title}tag[$:/TOC]limit[1]] works more than 10 times faster!
649.20 ms Thank you for your plugin!

1 Like
#33

I saw recently mentioned that rather than all[current] that <currentTiddler> is now concidered the most efficient way to target the current tiddler.

Lets look at this filter and its intention [all[current]tagging[]tag[$:/TOC]limit[1]].

  • look for all tiddlers tagged with the current tiddler
  • if those tiddlers list those which have the $:/TOC tag. Limit this to one, as we want to know it tags at least one tiddler on the top of the toc?

Can you clarify @Siniy-Kit and I think we can improve it.

#34

That’s interesting, I’d like to hear more, if you or anyone else can find the source discussion.

I always thought they work identically and used them interchangeably. I couldn’t find any explanation of differences between them in the docs.

Edit: I have found Maurycy’s investigation in this thread. According to these tests, <currentTiddler> is the fastest indeed, but both methods are so fast it shouldn’t matter which one is used.

#35

A long time ago there was a debate abount [is[current]] and [all[current]] and it was determined [all[current]] was the most efficient and I use it as a rule, which I am about to change to [<currrentTiddler>] but I think is safe to say [all[current]] is not intuitive because its like saying;

All tiddlers that are this one, single tiddler.

So a compelling reason to use [<currentTiddler>] is it makes sense.

I think @EricShulman raised this recently.

#36

long ago Bj wrote a little list-cache-extend.js to disable all $list refresh on every click . And I was sure, that it works on all lists. But Maurycy’s plugin
shows that my old variant of TOC macros works very slow and refresh on every click. Here is my new variant TOC and list-cache-extend.js works on it. So I think that

<$macrocall $name="toc-body" .....

and

<<toc-body>>

are different in performance too.

1 Like
#37

thread bump. I installed this last week and it’s great to be able to see the performance at a glance.

However, the demo and the git repos both seem to top out at 1.1.4 - are the updates available, or awaiting a merge and push perhaps?

(I was going to request the ‘Time taken’ be able to be coloured according to thresholds of time, hence finding this thread and discovering the version discrepancy here!)

#38

Uh. Whoops.

What happened was I absentmindedly made the changes in a branch for a different unfinished plugin and somehow I never noticed nor brought it back into main.

Fixed that, it should now be up on the page and in the repo!

1 Like
#39

hah, easy to lose track of a place in a repo. Been there myself. Thankyou for the find and release :slight_smile:

So with that out of the way, a minor feature request - having it draw a bit more attention to itself when the performance is poor.

My thinking is something as simple as setting the background-color of #ec_ep-total-time - default when the value is <200, yellow for 200-400, orange for 400-600, and red for 600+ (or other thresholds that make more sense perhaps?)

My thinking is that I am reasonably happy with leaving this enabled at all times, and occasionally glancing and paying attention randomly, and checking it in a bit more depth when I’m testing a bit of basic TW markup/code, but I dont know how often it bumps over those thresholds on the occasional quirky thing, and it’d be nice to have it draw that attention at the moment of performance concern!