perf(oxc_ast): reduce ast memory usage

[IWANABETHATGUY]

part of #5601

[graphite-app]

Your org has enabled the Graphite merge queue for merging into main

Add the label “0-merge” to the PR and Graphite will automatically add it to the merge queue when it’s ready to merge. Or use the label “hotfix” to add to the merge queue as a hot fix.

You must have a Graphite account and log in to Graphite in order to use the merge queue. Sign up using this link.

[codspeed-hq]

CodSpeed Performance Report

Merging #5645 will not alter performance

_{Comparing perf/optimize-ast-layout (83ae461) with main (e38114b)}

Summary

✅ 29 untouched benchmarks

[overlookmotel]

I'm afraid these changes so far don't make sense to me. The indirection of Box has a cost, so generally speaking should be avoided unless necessary.

In my opinion, the fields which we should consider boxing are either:

1. Large and wrapped in a Option, which is often None.
2. Vecs which are commonly empty.

e.g.:

• Class::decorators (most classes aren't decorated, so this Vec is usually empty).
• FormalParameter::decorators (ditto)
• FunctionBody::directives (most functions don't have any directives)
• ArrayAssignmentTarget::rest ([a, b] = arr is more common than [a, ...b] = arr, so rest is usually None)

In particular, I imagine that the majority of code that Oxc will run against will be plain JS (when bundling an application, the volume of code in node_modules will likely dwarf the application code written in TS). Therefore I think we should optimize the AST to be as memory-efficient as possible for JS, by boxing large TS-only fields.

Side note: We can expect Vec to be reduced to 16 bytes in future, which will reduce the size of a lot of types. oxc-project/backlog#18

[overlookmotel]

This change doesn't make sense to me. It introduces indirection to save 8 bytes. And it's not really saving any bytes anyway as the Expression is still stored in arena, just in a separate allocation - in fact overall it costs an extra 8 bytes for the additional pointer.