(future) ESR115 & better JS profiling

**wraitii** · May 25, 2023

Good news and bad news about the future.

As of Firefox 115, which will be the latest ESR soon, I can finally properly profile the game including JIT code.
The only thing to do is compile spidermonkey with `enable-perf` and `--enable-jitspew` (I think), then run it form within https://github.com/mstange/samply like so: `IONPERF=func PERF_SPEW_DIR=. samply record -n --rate 10000 binaries/system/pyrogenesis -mod=public -autostart="random/continent" --autostart-ai="1:petra" -autostart-ai="2:petra" -autostart-nonvisual -autostart-seed=150`

This gives you a full profile that you can then access on the firefox profiler, like so: https://share.firefox.dev/3IHH7ho (AI 1v1)
There are some interesting overall insights:

In this AI 1v1 75-80% of the time is spent in C++ code. But a lot of that time is calls from JS.
As I have reported in the staff forums in the past, the main cost in the SimUpdate is `Timer Update` (about 15% of total time), split between ResourceGatherer, ProductionQueue, Builder, Attack, DelayedDamage.
Most of the code appears to end up properly jitted.
But the GCs 'dump' the JIT code regularly, which means we spend more time in baseline than we probably should. I have reported a bug about this, we'll see what happens: https://bugzilla.mozilla.org/show_bug.cgi?id=1834848
There is a fair amount of Spidermonkey overhead, though there are things we could improve.
- To take the Example of calling `Engine.QueryInterface`, the costs breakdown as follow:
  - ToJSVal<IComponent*> is about 40-45%. This is largely because of D5004.
  - The actual C++ QueryInterface is only 20%, which is slow because of std::map. But it's not the most major cost.
  - Getting the ComponentManager pointer is 7%
  - ScriptRequest enters the realm (for no reason), which accounts for about 10% total
- So as you can see there are a lot of things we could do to skip some time, but it's also going to be kinda hard.

Some obvious things that show up and could probably be improved:

Having a `Engine.QueryInterfaces()` function is probably interesting.
Identity:Init() is slow because of splitting the identity classes. We can cache that in ParamNode directly I think.
There are some regex constructions in loop which are slow, such as in MatchesClassList
AI Interface and AI Proxy are fairly slow.
The AI in general also seems poorly jitted, and that might have to do with how the objects are structured, hard to say.
Modifiers are kinda costly, but we knew that.

Now, right now we are still on ESR92, so this is some ways off, but I have compiled it on a local branch, and I think the results are rather interesting, and encouraging for the future.