tree_arena: Use hashbrown::HashMap as drop-in replacement to optimize tree-access

[Philipp-M]

As noted in #772 (review), this seems to be a really cheap but quite effective optimization, as we have hashbrown already 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::elapsed in the event loop (so rendering is not included, but I think there's also a speedup as we're iterating the tree).

[waywardmonkeys]

Don't count me as the approving approval for a merge, but I'm +1 on this sort of change as long as you don't care about the DoS resistance ... this is a very common technique for good performance gain (that I use a lot elsewhere).

[Philipp-M]

you don't care about the DoS resistance

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 Grid, Flex and SizedBox, not sure if that should even be the case...
Maybe we should remove that possibility, as I currently don't see an advantage for this...

[DJMcNab]

Thanks. I think we can land this. It is surprising quite how hash-lookup dominated we are.

[KGrewal1]

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)

[Philipp-M]

It is surprising quite how hash-lookup dominated we are.

Yeah definitely, thought it would be measurable, but that it has this much impact...

I understand it may not be reproducible, but would be interested in looking more at your perf tests

Basically I used the mason example set it to "unlimited power" (data.active = true) with data.count = 10000 and then a simple elapsed = Instant::now() - now_at_beginning_of_handle_signals at the end of MasonryState::handle_signals, filtered too small values out (e.g. when nothing has changed), and to get a better picture, averaged these values over multiple frames (should probably look into more sophisticated ways to profile).

I wonder if in combination with the faster hashmap, and by mapping to a vector of children

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.