Optimize unresolved references in semantic

[overlookmotel]

#4162 boosted perf of semantic by turning unresolved_references into a stack.

I think we can potentially do even better. From #4162 (comment):

What I had in mind is that you never call unresolved_references.pop(). Instead, hold on to the hash map and re-use it. That way we avoid generating (and allocating) new hash map when entering a scope most of the time.

unresolved_references is Vec<UnresolvedReferences>, indexed by scope depth.

e.g. with this input:

function foo() {}
function bar() {}

• Enter top level scope:
  • Depth is 0.
  • Push a UnresolvedReferences hash map to unresolved_references.
  • Current hashmap is unresolved_references[0].
• Enter scope for foo:
  • Increment depth to 1.
  • Push another UnresolvedReferences hash map to unresolved_references.
  • Current hashmap is unresolved_references[1].
• Exit scope for foo:
  • Clear current hashmap (unresolved_references[1]).
  • Decrement depth to 0.
  • Do NOT pop from unresolved_references.
  • Current hashmap is now unresolved_references[0].
• Enter scope for bar:
  • Increment depth to 1.
  • Do NOT push to unresolved_references.
  • Current hashmap is unresolved_references[1] (i.e. reuse same hash map that was used for foo)
• Exit scope for bar: same as for foo
• Exit top level scope: same

I think this would be a further perf boost due to reducing allocations, and reusing allocations which are already warm in the cache.

cc @lucab (though no obligation on you to do this)

[Boshen]

Hashing into UnresolvedReferences remains the slower part of the pipeline. Are there any other improvements can be made before storing the hash value inline?

(I'm currently working on the mangler, which involves rebuilding the symbol and scope tree again.)

[overlookmotel]

Are there any other improvements can be made before storing the hash value inline?

Very likely yes. See point 7 on oxc-project/backlog#32 (I only added it earlier this week).

We should certainly be able to reduce hashing, but I don't know the internals of the hashmap we're using well enough to say best way to do it. We may not even need to store the whole hash, maybe just the top 7 bits of it (if it's a SwissTable-style hashmap).

But that's orthogonal to the optimization described in this issue. Both will improve perf independently, and it'd be even better if we can do both.

[overlookmotel]

Fixed in #4213.