Which performance work would you accept first, ahead of a JIT?

[LinuxBoy-96]

Context: on script-heavy pages, property access, calls and GC dominate well
before any JIT question, which matches the conclusion in #4487 that bytecode
dispatch is not the main cost. I'd like to contribute performance work in
mergeable increments, and I'd rather align with you before writing code.

Reading 0.22, the property-access side is further along than I expected:
vm/inline_cache already has 4-way polymorphic ICs keyed on Shape, wired
into GetPropertyByName / SetPropertyByName. What I did not find is any
form of lazy function compilation: bytecompiler::function() compiles
every nested function through FunctionCompiler::compile while compiling
its parent, so a multi-megabyte bundle is fully parsed and compiled to
bytecode before the first instruction runs. On page bundles most functions
are never called during load, so this is startup time, not execution time.

Four questions:

1. Lazy compilation. Since the source text of each function is already
   kept (SpannedSourceText) and parse_function_body exists for
   new Function, one design is: at compile time, store the source span plus
   the parent scopes instead of a CodeBlock; on first call, parse that span
   and compile it. The hard part is scope_analyzer, which would need to
   accept an existing parent scope chain instead of a fresh global scope.
   Would you consider this, and is that analyzer change acceptable — or do
   you see a better way?
2. Inline caches. Is there a plan or branch for computed-key access and
   method-call sites, or is the current coverage what you intend for 1.0?
3. Call path. Is there appetite for a fast path for the common case (no
   rest/spread, no arguments, known arity), or is that gated on the IR work
   described in Boa and JIT #4487?
4. GC. Is a generational or nursery collector on the table before 1.0, or
   is the current mark-sweep considered good enough until then?

I'll post parse+compile timings of a real bundle measured with boa_cli
here, and bring a first PR sized for review on whichever item you'd look at
first.

[mansiverma897993]

I suggest starting with benchmarks before making a large VM change. We should measure parsing, scope analysis, bytecode compilation, execution, and GC on a real script-heavy bundle.
If compilation is the main startup cost, a safe first experiment is lazy bytecode compilation but parsing and early-error checks must remain eager so JavaScript behaviour does not change.
A targeted inline-cache improvement may be a smaller first PR. I would defer generational GC because it needs a much larger design change.
Which direction would maintainers @jedel1043 prefer first: benchmarks, inline-cache work, or a small lazy-compilation prototype?
I would defer generational GC work for now: it is a larger collector architecture project and likely needs a separate design discussion.

[LinuxBoy-96]

Numbers, as asked. YouTube's main page bundle (10.5 MB, ES5 build),
measured with a small harness timing Script::parse, Script::codeblock,
Script::evaluate and one force_collect separately (release build):

• parse + scope analysis: 6.58 s
• bytecode compilation: 7.33 s
• execution: 45 ms (stops at the first missing DOM global)
• full GC: 23 ms

So on a page bundle, ~14 s pass before the first instruction runs, and all
of it is parse + compile; execution and GC are noise at load time. Two
conclusions:

1. Lazy bytecode compilation (parsing and early errors staying eager, only
   FunctionCompiler::compile deferred to first call) would remove most of
   the 7.3 s, since the vast majority of functions in such a bundle are
   never called during load. I'll prototype that first, behind a flag.
2. The parser itself runs at ~1.6 MB/s, which looks allocation-bound rather
   than inherent; worth profiling separately once (1) lands.

Happy to share the harness if useful (40 lines against the public API).

Change phases.txt to phases.rs
phases.txt

[jedel1043]

@LinuxBoy-96 Thank you for your work on this!

• 1 makes sense, I think there was an issue about that but if not then it would be a good thing to implement.
• 2 also makes sense; our AST representation is not using an arena, so all new nodes need to reserve new heap space for them, which wastes time and adds more cache misses to the parsing. IIRC we had a PR that implemented that, but it got stale, so it might be good to see if we can salvage some of that to save time on parsing.