Boa's start-up time getting hit with GC Allocation

[jasonwilliams]

Boa spends a large proportion of time in realm creation comparitive to actually running the code.
It seems a lot of this is due to building out the global objects on the heap and storing them causing the GC to do multiple collections before the program has even started.

We may wish to look at some sort of snapshot for built-ins or staticlly storing them somewhere (switch of GC for built-ins)

You can load the below profiler into ui.perfetto.dev or chrome developer tools and take a look.

chrome_profiler.json

[nekevss]

Raising the threshold at the below might help.

boa/core/gc/src/lib.rs

Line 66 in fc2a6e0

threshold: 1024,

[raskad]

Raising the threshold at the below might help.

boa/core/gc/src/lib.rs

Line 66 in fc2a6e0

threshold: 1024,

Yeah I also think we should raise the default threshold and make it configurable from outside of boa_gc.

[jasonwilliams]

I ran cargo run --profile=release-dbg --bin boa --features=dhat debug/script.js

Hello world!
undefined
dhat: Total:     611,648 bytes in 3,019 blocks
dhat: At t-gmax: 382,386 bytes in 2,283 blocks
dhat: At t-end:  354,488 bytes in 2,258 blocks

Also I've noticed that in DHAT we spend a lot of time growing the vector for property_table.

If we know ahead of time how many static methods are on a builtin, we should be passing this number through so it can create the vec::with_capacity(n)

[jasonwilliams]

We’re not able to set each property_table with a capacity right now due to the fact that for each template the inner shape is cloned from the first shape.

We may need to set new root shapes here, each one having its own set of prototype storage capacity and property capacity.

@HalidOdat thoughts?