-
-
Notifications
You must be signed in to change notification settings - Fork 4.5k
chore: improve old value implementation performance #15854
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
🦋 Changeset detectedLatest commit: cf263ab The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
Visual benchmark comparison:
While this PR is faster on some benchmarks, it's slower on others. It seems like using a linked list should be very slightly faster in the common case but significantly slower in the pathological case, and since we're talking about microseconds in the common case it might be preferable to keep the existing implementation, especially since it's much simpler? Or is the current implementation causing real-world performance issues? |
Was that with the other PR merged too? It's odd because locally I get different results than you do, but you can still see that the kairo benchmarks are benefited. I wonder if we can improve on this PR though by:
|
It was with the other PR merged, yeah. Just brought everything up to date and did another run with similar results: updated results
So yeah, Switching to a Map at a certain threshold feels like a bad choice — we can't really know what the appropriate threshold is across different machines/engines, and it adds even more complexity. As for 'if there's no teardown used' we would always hit false negatives, because the existence of |
Let's leave this optimisation out of it then :) thanks for digging into it and reviewing though. |
This improves the signal runtime performance by opting for a linked list rather than a Map for storing old values. In theory a Map should be O(1) for lookups, but they come with overhead in terms when both setting a value and when clearing the Map down. Instead, using a linked list avoids this overhead except in the case where there might be many signal changes in the same update – in which case, maybe we should still opt to use a Map for those cases. Here are the benchmark results:
Main:
This PR: