To be fair - I've never seen such docs for SpiderMonkey. I may have just failed at finding them though.
Keeping up-to date documentation of compiler is a horrible job. I think it's good enough that V8 may be built as standalone binary with really extraordinary debug options and tools.
SpiderMonkey isn't a shining city on a hill in this case, certainly. In my experience though the docs that are there are easier to understand, the log messages are more verbose and understandable, and the developers are easier to get help from. I think this is all just a result of the fact that Mozilla relies more on community involvement to get stuff done, so they have to be a bit more dev-friendly.
The same dislike of documenting performance details and internals exists on the SM team, though.
Standalone binaries with debug options like d8 and spidermonkey js.exe are great for narrowly-scoped tuning and microbenchmarks, but in the real world your app runs in the browser and you end up having to debug and profile it there. That's where the whole picture falls apart (and where Spidermonkey's tools are dramatically better).
Mozilla ships two different performance analysis tools for in-browser JS that give you extremely detailed, precise performance information (JIT Inspector and SPS). They're more stable than Chrome's tools on average as well. You can literally get the browser to dump the native assembly it produced when JITting a given function.
I haven't done any perf tuning in a while, so this page is probably out of date, but I've made a point of documenting the stuff I discover about each engine, and linking to sources where possible:
https://github.com/sq/JSIL/wiki/JavaScript-Performance-For-M...
> You can literally get the browser to dump the native assembly it produced when JITting a given function.
You can literally get Chrome to dump native assembly it produces when JITting a given function. You just need to build Chromium yourself, because disassembler is not built into it. It's a dead bloat I guess for 99% of people, even for JS VM engineer disassembly is the last resort. You can get compiler IR from any Chrome build and people do get it. And usually it means that VM itself should be fixed.
People should not need to care about IR or (worse) disassembly. If your code is reasonable it should just work reasonably fast. File bugs if it does not, instead of tuning, which can break as soon as V8 moves left or right.
To be more precise, the Firefox addon that does this lets you select a specific function and view the assembly on demand, instead of getting a multi-gigabyte IR/assembly dump from a debug build of the browser. That's what makes it useful.
I agree that in general users should not need to care about IR or disassembly. Unfortunately, I'm not sure we'll ever end up in that world.
I see, yes just printing a simple function on demand is indeed quite useful.
IIRC V8 has Debug.disassemble(f), requires both a special build and mirror debugger exposed to the page. Prints disassembly to stdout. Can be tweaked to return disassembly as string, but that requires knowledge of V8. (I actually don't know who is the client of this function or why it was added).
[side note: if you get function disassembly you can't really be completely sure that that's the code that was running 2 seconds ago, that's one of the reasons why V8 just dumps everything]
I was trying to get disassembly of asm.js compiled by IonMonkey a couple of months ago. I had to run SpiderMonkey under gdb and disassemble the JITted entry points. (Or maybe I didn't...)
I don't know if this dumps the disassembly for asm.js. I suspect it can't, since asm.js modules are AOT compiled into a single big block of code - but maybe it'll work. Give it a try!
> People should not need to care about IR or (worse) disassembly. If your code is reasonable it should just work reasonably fast. File bugs if it does not, instead of tuning, which can break as soon as V8 moves left or right.
The trouble with this is that the results are not in your own hands. Developers have bosses and deadlines and all that, and when it comes down to it, they just need to make it work. In that position, it's awfully hard to "submit a bug report and pray," and though it's not optimal, the ability to get into the guts of things can satisfy the immediate need.
> it's awfully hard to "submit a bug report and pray,"
You don't need to be praying. If no immediate fix can be made in the V8, you will get some recommendations and explanations based on the V8 team knowledge.
I would go as far as saying that bug reports like this are a single most reliable signal of what JS developers want to be fast on the web. By not reporting performance issues and silently working around them you hinder this signal. THere might be bugs and inconsistencies in underlying VM optimizations that can go unnoticed for a long time due to that.
Keeping up-to date documentation of compiler is a horrible job. I think it's good enough that V8 may be built as standalone binary with really extraordinary debug options and tools.
At the same time, I'd love to see more talks like http://www.youtube.com/watch?v=FrufJFBSoQY There are also guys who write about V8 from time to time (http://mrale.ph/ http://floitsch.blogspot.com/ http://wingolog.org/tags/v8) but this is needle-in-a-haystack type of learning.