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
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The all filter operator has shortcuts to optimise common patterns like [all[shadows+tiddlers]] or [all[tiddlers]]. In those cases, the filter operator function returns early and never uses the result linked list that was created, so it's immediately garbage-collected. This PR attempts to speed up the result of calling all in those common cases by only creating that linked list if it's actually going to be used, avoiding that garbage collection in the common cases that are optimised to return early.
The `all` filter operator has shortcuts to optimise common patterns like
`[all[shadows+tiddlers]]` or `[all[tiddlers]]`. In those cases, the
filter operator function returns early and never uses the `result`
linked list that was created, so it's immediately garbage-collected.
Let's delay creating it until we know it's actually going to be used.
All unit tests still pass with this PR. I have not yet figured out how to measure the performance benefits you get from this optimisation. I expect it to be relatively small, as creating a $tw.utils.LinkedList object allocates about three objects (the linked list and its next and prev properties, which are LLMap objects) with about 5-6 allocated properties total. That's not a huge amount of memory to churn: a couple dozen bytes at most. However, the [all[shadows+tiddlers]] filter is used all over the place in TiddlyWiki's internals, and every one of those filters is currently allocating a LinkedList and then immediately throwing it away without using it. So those dozens of bytes, and the work the Javascript garbage collector has to do to keep track of them, will eventually add up to some measurable amount of time, I just don't know how large a wiki will need to be before it's noticeable.
@flibbles - You originally created #5362 in order to optimise the performance of the all operator, and this PR is simply building on your work a little. In that PR, you wrote "There's more room for improvement by cutting down all that garbage collection ...", and I think this is a small step in that direction. Since you already have a test wiki set up for performance measuring (or at least, you did at the time you created #5362), would you be interested in using it to measure the speedup obtained by this small change?
I do not have a test wiki set up. Your change seems pretty simple. It either helps or it does nothing. It won't hurt. I'm not sure it needs a run of performance testing.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The
allfilter operator has shortcuts to optimise common patterns like[all[shadows+tiddlers]]or[all[tiddlers]]. In those cases, the filter operator function returns early and never uses theresultlinked list that was created, so it's immediately garbage-collected. This PR attempts to speed up the result of callingallin those common cases by only creating that linked list if it's actually going to be used, avoiding that garbage collection in the common cases that are optimised to return early.