Interesting confirmation of my observations
What is interesting to me is that the core of this code, which was absorbing more than 90% of the time, was a fairly simple pair of loops that had no recursion nor anything else fancy at all.
It's so easy
Forget all that dynamic mumbo-jumbo of JITing and interpreting. Just download the stuff, compile everything to the last statement into machine code and fire it off. Delphi has demonstrated that a compiler does not need to the the sllooowwwisshh C++ clunker.
Also, if you see the same script twice, just grab into your cache and get that version you compiled yesterday.
Re: It's so easy
If it were, you'd have read the article - the problem comes when *tracing* the code (which is why it's called TRACEmonkey). If you compile it whole-sale, you loose the human-readable traceability.
or combine the two approaches -- try googling for "slim binaries" of Oberon.
Mozilla people heard your ideas then?
@jlocke - I'm sure if your ideas are provably good then they'll adopt them.
I agree with jlocke - doing the old fashioned thing of compiling to a native executable is surely going to give the best performance. And surely no script download speed can be swifter than a compiler, so what's the problem with JOT (just one time) compiling?
Not if the compile time
outstrips the run time. Tracing can give benefits over full compilation in specific situations.
Why re-use when you can re-invent the wheel?
Yes, because Java and .NET are well known to be fast and entirely effective at driving events on a webpage.
How does .Net technology help on most of FF's non-MS platforms? And, why would I want to bolt JS onto a JVM?
Last but not least, I would rather have JS execution kept well away from any .Net/JVM I might have on my machine. You know, that outdated and bizarre concept called sandboxing that I have an irrational fondness for.
To the FF team - great work guys, keep at it.
Precompiled executables cached from trusted CDNss
Mozilla has spent a good deal of time and effort with their add-ons database all provided under a Mozilla SSL cert and with full security checks. As such, with JS libraries like jQuery, prototype and MooTools as well as commonly used helpers like swfobject or scrip.aculo.us all hosted on a variety of Content Download Networks (CDNs, ie like google's: http://code.google.com/apis/ajaxlibs/documentation/ or the MS equivalent: http://www.asp.net/ajaxlibrary/cdn.ashx).
This will this fix the appalling, treacle like behaviour firefox demonstrates in gmail
More Caffeine ......
It is as well to remember that in darker ages was all code alien and freely available. Now it is a plaything to monetise in Unconventional and Irregular Conservative Capitalism.
And QuITE a Colossal Mozilla Project for Military Monied Media Moguls too for the Holy Trinity of Might, Means and Message in AI Singularity HyperRadioProActive, is an Impossible Strain to Train and Enjoy with Insatiable Passions ..... ergo is IT a Labour of LOVE Extraordinarily Rendered and Delivered for You Too To Use/Experience/Driver.
"The JaegerMonkey project is only about two months old - and it's a ways from testing in a Firefox beta build - but a blog post from Mozilla programmer David Anderson says it's already providing a 30 per cent performance boost over that old interpreter on x86 machines." ..... Hmmm. Cade, what is to say that this post is not exercising and performance testing a Particularly and Peculiarly Stealthy Firefox beta build Launching the Browser into Quantum Fields of Registered Search Product Placements ...... Virtual Reality SpaceScapes/CHAOS Diaspora.
Or is that Google's Master Oracle Plan to Out Vanquish Microsoft?
How much easier would that make life for a malware author, or a hacker. Apart from the fact that Firefox compiles on the users computer not on some domain owned by Mozilla, what then would be use of what you suggest, other than to slow down or freeze Firefox to an unusable pace.
Agree with Bob 18 entirely, scrap Java altogether, it's more hassle than it's worth.
Errr... Java-_script_, Neal.
The CP is authenticating itself using https. This would result in about the same download times as the current arrangement and zero compilation time (after the initial compilation).
I suggested this idea for Java also. Maybe Larry will finally make a proper version of Java available....
My coffee's cold
Could it be that the problem is Java, not the compiler methods?
Insanity: Doing the same thing over and over again and expecting different results. Albert Einstein.
Try to keep up.
Even with the re-interpretation, it doesn't get any better does it. Asuming (to be genorous) a 30% market share for Firefox, that's going to be 30% of the worlds bandwith eaten up at any one time, simply by Firefox checking home periodically. Some will put Firefox's market share even higher, some even less, the point is, whatever the market share Firefox actually does have, the corresponding % of bandwidth dissapears.
So maybe Firefox will become the fastest browser on the web, at the expense of the internet as a whole, who's going to buy that?
I am not sure what you are talking about. Firefox updates ? My suggested scheme ? The first is surely much less than the html traffic.
When it crashes..
.. you get a Jäger Bomb!
does this mean
that experts in the field are Jägermeisters? Or is that just their preferred tipple?
@When it crashes..
No, then you should drink one of these:
Well, actually I would not suggest it. It tastes a bit strange.
Better go for the beer.
Still no improvement. 30% market share latching onto a web server, Sure anyone out there other than perhaps Google can handle that load?
Even if you went cloudy with it, what sort of a data centre architecture would be able to handle it?, and for what, so Firefox can save maybe 3 nano seconds on compilation. When in your world, does expense bear no reality to saving.? Let me guess, you work for RBS, or HBOS, possibly even Lloyds, that's the only place I can think of, where those sort of economies feature.
Best place for compilation is in browser, even better, scrapping Java altogether.
You could run that Compilation Proxy also in your intranet. It would make the browser lighter, as the compiler is not pushed to each and every desktop. Secondly, this would ensure the confidentiality of your inhouse JS apps.
And, performance IS a Big Issue. Applications like Google Docs need all the JS horsepower they can get and more and more other applications also.
You can do really nice things with JS, and I think Google Apps is just a glimpse of the future. And certainly, the faster JS becomes, the more things will be possible.