Time for a Jäger shot
TraceMonkey speeds performance by detecting code loops and converting them into assembly language. "We find places where code gets executed more than once," Blizzard said. "We basically optimize that code and trace it to native code."
But there are cases where this sort of thing just doesn't work. This happens with, say, recursion or heavily nested code. As it stands, when tracing fails, Firefox falls back on an interpreter that runs JavsScript at circa 2007 speeds.
With JaegerMonkey, Mozilla adds a Just-in-Time (JIT) engine much like those used by the other major browsers. The extension is actually based on the Nitro JIT used by Apple Safari. Firefox will still do tracing – something other browsers don't do – but it will be able to fall back on the baseline JIT, converting entire methods into assembly language.
"The important thing to realize is that we know we have a lot of things we can to do to optimize for really intensive web apps that will get us within [striking distance] of native code speed," Blizzard said. ®
If you want to get the last 70 % performance out of an Intel or AMD CPU you need to handcode your innermost loops in assembly. And use things like SSE, of course.
And whatever you do, compilation is very, very CPU-intensive. It should not be done for each and every client again. Rather, use RTL and Compilation Providers/Caches. Which can be inside or outside your intranet. Secure it with digital signatures and trusted providers (like Google, MS, Oracle, IBM, Rhat, Canonical, etc).
If you do it in Flash (like many sites let you do), you can apply the filters in real time, full 24fps. Oh well.
re: GC, Assembler
Java != GC, GC != Java
> IF they exist (like Eclipse or VS2010) they are consuming memory very liberally
Well eclipse is 'written primarily in Java' <http://en.wikipedia.org/wiki/Eclipse_software> and VS2010 is written in C++ & C# <http://en.wikipedia.org/wiki/Visual_Studio_2010> which is presumably a mix of GC & non-GC.
As to their bloat, I use emacs (GC'd lisp) which is tons smaller than those monsters. Perhaps bloat isn't solely down to use of GC or a given language? Maybe featureitis?
Re. CAD I can't, but I note that Autocad has a GC'd lispy front end. Horses for courses perhaps.
There's also wings, written in erlang I believe <http://en.wikipedia.org/wiki/Wings_3D> but it's more a personal project than commercially important software. It can export to Blender which per the wiki page uses python for the scripting - presumably because a slower but higher-level GC'd lang is more appropriate for end use than C? Horses for courses like I said.
I worked on a system which was GC'd using refcounting. It was horrible performance-wise but the lead programmers thought it was worthwhile when they started & felt they'd made the right decision at the end. It was arguably the crappiest form of GC to implement but it worked for them because it allowed them to concentrate on the relevant deliverables, not low-level pointer management, the delays & general bugs of which would have sunk the project & the company, I guarantee it.
Horses/courses. A feature or language's superiority is in the context of its use, not intrinsic to the language.
Regarding SSE, well, you have the edge over me with your experience. I'd only note that I'd not expect signal processing stuff to be done in jscript, but that's maybe not a fair criticism as flops are useful in many areas.