You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on May 28, 2023. It is now read-only.
It looks like "Total Time" is calculated as the sum of all individual entries in the filter list. This can be significantly off when filters are nested, I think.
Take e.g. these definitions from a search tiddler:
Each usage of filtered-results will result in all the other filters being called. In the performance report it will show this (only a portion of the output is shown):
(the third line is the contents of "$:/mwi/ui/GoTo/config/sort" in the second line, the fourth line is the chrono-subfilter called in the third line)
As far as I can tell, in this list, the runtime for each filter includes the runtime of its subfilters. So, if you just add them all up, you'll count the runtime of the subfilter twice – once its self time and once for the calling filter.
Since all of the above lines are subfilters of the first line, the total time would be 304 ms, not 1.3 s as reported in "Total Time".
I'm not sure this is something that can be fixed easily, but maybe you can add a note to the docs?
The text was updated successfully, but these errors were encountered:
@yaisog Oh wow, great catch! It should be simple to fix, I'll make it so that subfilters are still displayed but displayed slightly differently to make it obvious they were executed as a subfilter expression, then I'll make it so that they're not included in the summary in the first tab to avoid double counting them.
The subfilter executions are now clearly marked with a tooltip-title explaining things.
The subfilter execution is still counted in the main filter's run because A) it'd be a pain to do otherwise; B) It makes sense to include it there, since it's, after all, part of the filter's execution time
Since refresh times are calculated separately there was no double counting there,
It looks like "Total Time" is calculated as the sum of all individual entries in the filter list. This can be significantly off when filters are nested, I think.
Take e.g. these definitions from a search tiddler:
Each usage of
filtered-results
will result in all the other filters being called. In the performance report it will show this (only a portion of the output is shown):(the third line is the contents of "$:/mwi/ui/GoTo/config/sort" in the second line, the fourth line is the
chrono-subfilter
called in the third line)As far as I can tell, in this list, the runtime for each filter includes the runtime of its subfilters. So, if you just add them all up, you'll count the runtime of the subfilter twice – once its self time and once for the calling filter.
Since all of the above lines are subfilters of the first line, the total time would be 304 ms, not 1.3 s as reported in "Total Time".
I'm not sure this is something that can be fixed easily, but maybe you can add a note to the docs?
The text was updated successfully, but these errors were encountered: