If I hack jstracer to allow http://dromaeo.com/?dom-quer to trace, it runs a lot faster (20% faster) than under JM. Comparing profiles, the number of total hits is about the same (because it's a benchmark that runs for a certain amount of time), but the call to getElementsByTagName takes 37% of the time under JM, and 43% under TM, say, on the getElementsByTagName(p) benchmark. The main difference seems to be prop gets. On TM, js::GetPropertyWithNativeGetter is about 16% of the time (6% self time, the rest calling into DOM code), while mjit::stubs::GetProp is 32% of the time (1% self time, 11% self time in InlineGetProp, 8% self time in js_NativeGet, the rest DOM code).

Key line from the test (line 54 in my local hacked copy): ret = elems[elems.length-1].nodeType; PIC output: [jaeger] PICs length disabled: getter (file:///Users/bzbarsky/mozilla/dromaeo/web/tests/dom-query.html: 54) [jaeger] PICs getelem disabled: unhandled object and key type (file:///Users/bzbarsky/mozilla/dromaeo/web/tests/dom-query.html: 54) [jaeger] PICs getprop disabled: getter (file:///Users/bzbarsky/mozilla/dromaeo/web/tests/dom-query.html: 54) So we still hit the propcache, I guess. But we end up doing it via the stub calls and stuff.... and lots of time is taken. :(

Obsolete with the removal of tracejit.

How is this obsolete? It's a performance regression in JM that needs fixing. It's not a bug about TM code!

That said, bhackett's IC work on JM may have fixed this. Need to measure.

Sorry, maybe I got a bit punchy. Current perf numbers, FWIW (m-c vs. Chrome 16) http://dromaeo.com/?id=156623,156624

More interesting in some ways would be numbers vs Fx8...

Your wish is my command! http://dromaeo.com/?id=156625,156623,156624

Ah, right. This stuff didn't actually trace in Fx8 anyway... I suspect we can worksforme this, though there is still a bunch of JIT work to make this stuff fast. Probably won't happen in JM, though. :(