[mishoo]

Speed is acceptable in Chrome, but the gap between V8 and other JS engines is stellar. :-\ So I'm afraid it won't be too useful for production use.

There's no debugger yet. It would be fairly easy to step through VM instructions, but to step through source code expressions looks quite complicated. First thing I'd like to do is to have a stack frame inspector.

What's unfortunate is that even the smallest new feature can have a quite dramatic impact on speed...

[jlongster]

If you track the expressions when compiling, you could embed them somewhere with information about which bytecode they refer to, and all you have to do when stepping is lookup the source expression. This kind of thing does tend to touch every part of the compiler though.

I work for Mozilla, but not specifically for Firefox, but I am interested to hear which parts were much slower for Firefox. If you have any jsperf or other test cases as examples, I'd love to see them and I can report back to the Firefox guys about it.

This looks extremely impressive though, I'm glad I don't have do all this work now to see how well a VM can perform!

EDIT: I was viewing your examples in Firefox, and they seem to perform rather well. Not incredibly speedy, but they seem close to the speed shown in the video.

[mishoo]

Well, I didn't benchmark specific parts of it, but here's a quick test (that's actually one of my favorite benchmarks now):

The program: (you can run it in the REPL; use C-S-y to paste from OS clipboard):

SS-USER> (defun sum (n) (let rec ((n n) (r 0)) (if (zerop n) r (rec (1- n) (+ r n)))))

SS-USER> (time (sum 100000))

The time spent will be displayed in the ss-output buffer.

Firefox: 6516ms Chrome: 138ms

Parsecs away... :-(

However:

(time (without-interrupts (sum 100000)))

Firefox: 376ms Chrome: 135ms

Still a lot worse than Chrome, but quite a big difference.

without-interrupts ensures that its body runs continuously. Normally we run 200 instructions of each thread, until we get to 50ms, then reschedule for later with setTimeout(0). So that's probably the reason why Chrome seems to do much better—maybe setTimeout is very expensive on FF.

[jlongster]

Thanks. I'm not sure about setTimeout, I can't imagine it's slow, but it might be something with context switching.

There's probably things you could do in the VM to optimize performance for Firefox. If you developed the VM in Chrome, typically people optimize for it Chrome. I can usually get relatively close performance if I tweak a few things here and there for both Firefox and Chrome.

Although, I think Firefox's main performance comes from JIT-ing, which you've totally lost if your running in a VM. The above example is a loop, which would usually perform great, but you've lost the JIT. That may be a reason.

[MaysonL]

OS X Safari 5.2: 173ms (2.0 GHz i7)