We spend 0.21% of the overall Speedometer 3 time creating Map and Set objects.
We are about 5x slower than Chrome at it, for example in createDep on TodoMVC-Vue or in _$Ek on TodoMVC-Lit.

Profile of MapObject::create: https://share.firefox.dev/3P07AJw

Allocation is the main problem. For a new Map object, we have three calls to js_pod_arena_malloc.

The following three reduced testcases compare Map/Set construction with JS array construction:

new Map() microbenchmark (attachment 9351654 [details]): 230ms in Firefox, 53ms in Chrome
new Set() microbenchmark (attachment 9351655 [details]): 230ms in Firefox, 53ms in Chrome
[] microbenchmark (attachment 9351656 [details]): 20ms in Firefox, 20ms in Chrome

For the curious, here's a breakdown of all Map / Set operations on sp3: https://share.firefox.dev/3sIG9wt (slow to load)

This bug isn't currently among the highest priorities for sp3-affecting JS work, but I expect it'll bubble to the top of the list eventually.

I think we do a malloc for the OrderedHashTable and then also for its variable-size table. Maybe we could store the OrderedHashTable in the object itself, similar to inline typed array data. Or we could fuse the two allocations into one. Or allocate it in the nursery if small.

It'd also be good to check how many entries we add in practice; if it's very small we'd ideally handle this without malloc.