tree_arena: Use hashbrown::HashMap as drop-in replacement to optimize tree-access
#774
Conversation
I don't think we really have to care about that (even if it would be an issue), as we're (almost) controlling the keys, i.e. the key is just an auto-increment in most places. I've seen that it can be manual in |
|
I understand it may not be reproducible, but would be interested in looking more at your perf tests: I wonder if in combination with the faster hashmap, and by mapping to a vector of children (instead of NodeId to child), plus possibly adding an iterator over children, if more speedups can be found #752 (comment) |
Yeah definitely, thought it would be measurable, but that it has this much impact...
Basically I used the mason example set it to "unlimited power" (
Yeah there seems to be a potential optimizing the lookup of children, when just the underlying hashmap does have this much impact, but should probably be discussed further on zulip (TreeArena topic?) or other PRs. |
As noted in #772 (review), this seems to be a really cheap but quite effective optimization, as we have
hashbrownalready in our dependency tree.I've noticed speedups of the rewrite passes of up to >100%.
On average about 20-50% and is also definitely noticeable (smoother and less latency).
Another quite interesting observation with my (admittedly not really reproducible) performance tests,
is that the safe tree arena is actually faster than the unsafe version (roughly 10-30%), and tells yet another time that benches are really important while optimizing...
Rough overview of my performance tests/benches:
I've mostly hovered over 10000 buttons in the mason example while testing, but every second or so a new button is spawned and also this is quite a bit faster.
I did a quick'n dirty
Instant::elapsedin the event loop (so rendering is not included, but I think there's also a speedup as we're iterating the tree).