|
|
|
|
|
by jlongster
5143 days ago
|
|
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. |
|
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.