I haven't profiled it yet, but my guess is that it's JS
The source for the slow one is at: https://github.com/adrianbg/n22d/commit/c8d171d3cc964bfb1f270b057532221289f0b61f The hottest pieces are: 531.0ms 3.4% js::mjit::stubs::FixupArity(js::VMFrame&, unsigned int) 424.0ms 2.7% CallCompiler::generateNativeStub() 396.0ms 2.5% bool js::gc::Arena::finalize<JSObject>(JSContext*, js::gc::AllocKind, unsigned long)
Assuming I did the git magic right to check out the right thing.... Looks like 42% of the time is methodjit generated code, 7% is under array_slice, another 5% doing generateNativeStub stuff around the array_slice. This is all under the NativeCall ic. 8% under array_extra, half of this calling back into JS. 5% allocating arrays directly from jitcode. Lots of stubcalls (FixupArity, CreateThis, GetElem, StrictEq, Arguments, FlatLambda). 2% actual mjit compilation via TryCompile. All those percentages are of total time, not main thread time. Main thread is about 92% of total; the remainder looks like the GC finalization thread, almost all self time in FinalizeArenas.
You need to log in before you can comment on or make changes to this bug.