Firefox Gets Massive JavaScript Performance Boost 462
monkeymonkey writes "Mozilla has integrated tracing optimization into SpiderMonkey, the JavaScript interpreter in Firefox. This improvement has boosted JavaScript performance by a factor of 20 to 40 in certain contexts. Ars Technica interviewed Mozilla CTO Brendan Eich (the original creator of JavaScript) and Mozilla's vice president of engineering, Mike Shaver. They say that tracing optimization will 'take JavaScript performance into the next tier' and 'get people thinking about JavaScript as a more general-purpose language.' The eventual goal is to make JavaScript run as fast as C code. Ars reports: 'Mozilla is leveraging an impressive new optimization technique to bring a big performance boost to the Firefox JavaScript engine. ...They aim to improve execution speed so that it is comparable to that of native code. This will redefine the boundaries of client-side performance and enable the development of a whole new generation of more computationally-intensive web applications.' Mozilla has also published a video that demonstrates the performance difference."
An anonymous reader contributes links the blogs of Eich and Shaver, where they have some further benchmarks.
As fast as C code??? (Score:5, Interesting)
Re:As fast as C code??? (Score:5, Informative)
Correct me if I'm wrong, but generally speaking, I was always under the impression that, as an interpreted language, javascript will never be able to run 100% as fast as natively compiled C code.
Well, it has a JIT compiler, so that would transform it into bytecode essentially. It's the reason why C# is as fast as C code, because it too has a JIT. Google JIT :)
Re:As fast as C code??? (Score:5, Insightful)
Does that also mean it's NOT as fast as native C/C++ code because C# is blatantly not and thus is part of the marketing guff that you were gulliable to believe?
Next you'll be telling me Java hasn't got obscene memory requirements in comparison to native C/C++...
Fast as C but uses lots more memory (Score:5, Informative)
In general, JIT systems can really provide CPU performance near C speed, or even faster for some benchmarks, once the application gets going. The catch is that you pay two penalties: startup time and memory. Lots of memory: for keeping stats on what needs compiling, trampolines to call in and out of the interpreter vs. JIT native code, and the native code *plus* the byte code.
Even dynamic languages like Python can have a JIT - it specializes a function for various combinations of argument types, and then provides a catchall generic version for general objects. The catchall version is not much faster than the interpreter, usually (in fact it could *be* the interpreter), but the specialized versions can be much, much faster. (Also blocks can be specialized within any of the function versions.) But all those specialized versions take up memory. So the JIT keeps stats and tries to make only the ones that really help.
Re:Fast as C but uses lots more memory (Score:5, Interesting)
The catch is that you pay two penalties: startup time and memory. Lots of memory: for keeping stats on what needs compiling, trampolines to call in and out of the interpreter vs. JIT native code, and the native code *plus* the byte code.
That JITs automatically incur large memory footprint or startup time penalties is the logical conclusion you come to if you look at the JVM. But the truth is that JITs don't have to suck as much as the JVM does.
For example, take LuaJIT [luajit.org], a JIT for the already-speedy dynamic language Lua. It speeds up Lua roughly 2-5x while starting up in less than 0.01 CPU-seconds and introducing less than 20% memory overhead [debian.org]. It also takes 2-8x less memory and starts up 10x faster than the JVM [debian.org], despite the fact that Lua is compiling from source, whereas the JVM starts with bytecode.
I've never looked at the source for the JVM, so I can't say just why it takes so many resources, but I can only conclude that it's because Sun just doesn't consider startup time or memory footprint a priority.
Re: (Score:3, Informative)
It compiled it into bytecode and references to variables, so it was reversible - just like Java.
The references built was then used during execution as offsets into a jump table, which meant that it was fairly effective and the variables were referred by address to the definition area and not by name, which also did speed up things.
See the link in my previous post for a few performance figures to compare with other systems of the time.
The really boring thing with that computer was that the graphics wasn't re
Re: (Score:3, Insightful)
Since web browsers usually can cache JavaScript it will be useful to cache the compiled JavaScript.
Next step is that we shall be able to see a server-side compiled JavaScript, but we will have to wait for browsers to support that. In that case we will be able to have language-agnostic browsers since the compiled code won't necessarily have to reflect which language that was used to write the script.
Re: (Score:3, Insightful)
You mean "in theory", not "in general". In general, real-world JIT systems are significantly slower than native code, though they certainly are noticably faster than regular bytecode, which in turn is faster than a pure interpreter.
Re:Fast as C but uses lots more memory (Score:5, Interesting)
So, really the memory access will be a bottle neck, you can never hope to have your program in cache and it will be much slower than C.
That's not always a given. If we go by the old rule of thumb that 80% of the time is spent in 20% of the code, we could stick that 20% in one place to maximize cache usage. You can even optimize so that if branches that are taken are kept in the cache, and infrequently executed branches are moved out of the way, maybe in a separate page so they can be swapped to disk.
You can do this to a certain degree at compile time, but often you don't know in advance what paths are going to be hot (it might be based on the data) and it may even change as the program runs.
In practice, if someone tells you that Java is faster that C, they're speaking mostly in hypotheticals. Java and another high-level languages encourage so many layers of abstraction that the sheer amount of code that needs to run will probably make it slower than your typical C program. There's also a lot of things, particularly anything that needs to be dynamic, that you can't easily/efficiently compile.
What's interesting is LLVM and .NET, where you can run C/C++ code in an interpreted/JIT-compiled environment. Potentially, with the optimizations mentioned above, you could have C code running in a virtual machine that's faster than statically-compiled C code.
Re:Fast as C but uses lots more memory (Score:5, Informative)
What's interesting is LLVM and .NET, where you can run C/C++ code in an interpreted/JIT-compiled environment. Potentially, with the optimizations mentioned above, you could have C code running in a virtual machine that's faster than statically-compiled C code.
HP did a lot of research on this about 4-5 years ago where they proved this was exactly the case. Do some googling for HP's Dynamo project. Real runtime knowledge of exactly what is being used and when leads to better optimistaion than static optimisation.
Re:Fast as C but uses lots more memory (Score:4, Informative)
"It wouldn't be JIT then, it'd have to be 'before the code is executed', because you wouldn't want the compiler to spring into action, run on core 2 whilst core 1 twiddles its thumbs waiting for the compilation to finish."
For example, in Java HotSpot it _already_ works this way. A special thread compiles the code while other thread(s) work in interpreted mode. When compilation is finished, other thread(s) switch to this new fast compiled code.
Also, there are optimizations in Java HotSpot which are _impossible_ to do using static analysis.
Re:Fast as C but uses lots more memory (Score:5, Informative)
So far JIT's just aren't as fast as C. They are very far along. People are using them for programs which may run for days at a time. This has more to do with having an easier time developing in a higher level language. In my experience java rivals and often surpasses C++ programs heavily reliant on the stl. Where I work, speed or features win marketshare and programs written in C are performance kings. Python and java are becoming more popular.
Re:Fast as C but uses lots more memory (Score:5, Informative)
What a bunch of stupidity...
First, "programs reliant on STL" can be as fast as anything on plain C. And very often they can be faster (for example, because dwarf-style exception handling is faster than return result checks).
Second, JITs are NOT "very far along". HotSpot is _already_ faster than C/C++ on some benchmarks. And it's only going to get better, because HotSpot can use real runtime statistics to guide optimizations (C/C++ can also use Profile Guided Optimizations but it relies on static data).
Re:Fast as C but uses lots more memory (Score:5, Informative)
but never compared to C.
Here [idiom.com] is a somewhat old comparison of Java and C/C++ performance, done by the University of Southern California. Note that the article was written in 2003 and updated in 2004. Javas performance has improved significantly since then, most noticeably in JDK 1.6. This is the conclusion:
Java is now nearly equal to (or faster than) C++ on low-level and numeric benchmarks.
Re:Fast as C but uses lots more memory (Score:4, Insightful)
http://psyco.sourceforge.net/ [sourceforge.net]
The really neat thing about it is that you can just load the module and call some functions, and it'll start JIT compiling your Python code for some moderate speedups (particularly string and number crunching). It doesn't need a special version of CPython or anything.
The original author is no longer developing it though -- he's working on PyPy [codespeak.net], the Python interpreter/JIT written in Python. I think they're up to about half the speed of CPython, which is pretty impressive considering how slow Python is.
Re: (Score:3, Interesting)
Does that also mean it's NOT as fast as native C/C++ code because C# is blatantly not and thus is part of the marketing guff that you were gulliable to believe?
Re:As fast as C code??? (Score:5, Insightful)
Yes. Javascript will, just like C# or Java, be as fast as C/C++ in theory, and just like C# or Java, slower in practice.
On the bright side... Javascript will be as fast as C# or Java, which is certainly good enough for a lot of things.
Re:Java/C#/C++/C equally fast (Score:5, Insightful)
Re: (Score:3, Informative)
Re:As fast as C code??? (Score:5, Insightful)
You are ABSOLUTELY wrong! C# by its very nature can not be as fast as C. There is no example you can provide where the running time of an optimized C version will be as fast or slower than the most optimized C# version. Even with JIT and supposed optimal native code generation for tight-loops there is no way you can get the same performance.
You are obviously just regurgitating MS marketing without thinking critically.
Re:As fast as C code??? (Score:4, Insightful)
C# by its very nature can not be as fast as C
C#, once JIT'ed, is just a bunch of binary. C, when compiled, is also a bunch of binary. Given a theoretically perfect JIT compiler vs the theoretically perfect static compiler, they'll both output exactly the same code.
You are obviously just regurgitating anti-MS propoganda without thinking critically :P
(Note: I'm not saying that C# implementations are *currently* as fast as C ones, just that there's nothing to stop them becoming so in the future)
Re: (Score:3, Insightful)
A JIT can work out the OS and exact chipset on which it is running and therefore choose to generate different native code optimized specifically for you system.
Even if a static C compiler happens to have been optimized for your exact CPU, cache size and memory a JIT could still collect or access runtime statistics about your application and do optimizations based on this information - this information is not available to a static C compiler.
Perhaps the .NET JIT sucks or always produces code that is slower t
C is inefficient (Score:5, Interesting)
You are ABSOLUTELY wrong! C# by its very nature can not be as fast as C.
The C# JIT has all the information that a C compiler has (essentially, the entire source code). In addition, it has a lot of global program information and it has runtime statistics. And, the C# language has better defined semantics. All of this taken together means that C# can be optimized better than C.
In terms of performance, C is a lousy language; Fortran is a "faster language" than C.
The only reason C even runs as well as it does is because people have invested 20 years in making compilers squeeze out the last cycle, because C compilers play fast and loose with C semantics at high optimization, and because even CPUs have been tuned to accommodate its semantics.
Re: (Score:3, Insightful)
Huh? You say that C is a lousy language for performance and then commence to list the reasons why it is a good language for performance?
No, I list the reasons why C programs benchmark well even though the language is hard to optimize.
Anyway... it seems C can be optimized better than Fortran [...] but real-world examples and benchmarks do not agree with you.
The fact that you think that those numbers are in any way relevant to what we are talking about just shows that you know absolutely nothing about benchm
Re:As fast as C code??? (Score:5, Informative)
Except that C# code isn't as fast as C code [debian.org]. It's 2.7 times slower.
Re: (Score:3, Insightful)
I'd have thought that it's possible in a limited scenario to produce the same machine code from various high-level languages. It surely depends on the compilation not the language?
[You're right, I'm not a programmer]
Re:As fast as C code??? (Score:4, Informative)
1) That's the Mono implementation of C#
2) Intel's C++ compiler is known to be one of the best but cannot handle all situations. GCC's takes 1.3 times longer. Java 'only' takes 1.96 times longer.
2a) Intel's C++ compiler got 3 errors in the benchmarks you linked to, thus it should have been disqualified. The Intel C got 1 error and a "no program", so again, disqualified. The first compiler to run all the tests was in fact the Gnu C++ compiler.
Ruby at 63x longer (or 30x slower than Java) should shut up all the Java haters who witter on about Ruby (or PHP at 12 slower than Java) for web development.
Re: (Score:3, Insightful)
Ruby at 63x longer (or 30x slower than Java) should shut up all the Java haters who witter on about Ruby (or PHP at 12 slower than Java) for web development.
nonsense :) if you want machine performance, go with C/C++. If you don't care about how fast your app runs becuase you're focussed on programmer productivity go with Ruby or Python. Java/C# therefore is a worse-in-every-case option :)
Re:As fast as C code??? (Score:5, Informative)
The optimization in the story is to compile parts of code written in Javascript. So when using this optimization, the Javascript is only partly interpreted, and if the compiled part is the part that takes up most of the runtime, then the Javascript could conceivably be something like the speed of natively compiled C.
Re: (Score:2, Informative)
Correct me if I'm wrong, but generally speaking, I was always under the impression that, as an interpreted language, javascript will never be able to run 100% as fast as natively compiled C code.
A real world Javascript program will rarely, if ever, be as fast as C. The idea with this is: Normally, loops, no matter how tight, are executed in the interpreter environment with all the overhead that it entails. The idea is to profile loops that are 'hot' enough to be compiled to machine code so that the following iterations don't have the overhead of the interpreter. The more iterations for a loop the potentially faster speedup. Since compiling in itself takes time obviously part of the profiling will b
Re:As fast as C code??? (Score:5, Informative)
Clue phone guys. Ring. Ring.
C is a high level language and like all high level languages it can either be compiled, interpreted, or even translated. JavaScript is no different than C and can also also be compiled, interpreted, or even translated. There is nothing special about the C language that makes it inherently faster than other languages. C itself is a derivation of the language BCPL, whos shortcomming was a lack of datatypes. The design goal of these language syntaxes was parsing with minimal overhead because RAM was in short supply in those days. C was not designed to be "faster" than anything.
C is commonly mistaken to be superior because the most popular C compilers are commonly more advanced than the compilers of other languages due to simple supply and demand metrics. C is more popular, so its compilers have traditionally gotten more development effort. C itself isnt special beyond its popularity.
Re:As fast as C code??? (Score:5, Informative)
Re: (Score:3, Interesting)
It's true that dynamic typing is a clock-cycle hog, but almost all new languages use it... I'd be perfectly happy with a strongly-typed variant of Javascript if it will run faster.
Re: (Score:3, Interesting)
The overhead of dynamic types is quite immense
That is a common myth but unless you call a factor of 2.0 immense, it it wrong. The truth is that the cost is immense only in the most naive implementations (*cough* ruby *cough). For example, while the compiler has to insert type checks whenever you do something like "+", with a well designed implementation that uses pointer tagging that should cost at most one bitwise-and and one branch-if-zero (with modern CPU pipelines that should cost a fraction of a cycle since the branch should predict fail and in
Re: (Score:3, Interesting)
Re:As fast as C code??? (Score:4, Interesting)
you want "memory allocation voodoo" in a lower level language? easy. overload the new operator in C++ and you're done. We did this for a very very fast, very very scalable system ages ago (back when 900mhz CPUs were teh win). You basically pre-allocate a pool of fixed-size blocks (eg 16 bytes, 32 bytes etc) then grab the first free one off the relevant pool when you need an object. And without the overhead of a garbage collector too!
Re: (Score:3, Interesting)
Re:As fast as C code??? (Score:5, Interesting)
For what it's worth tracemonkey is about the same speed as unoptimized C on integer math at this point. The difference is register allocation (which tracemonkey doesn't do yet).
Moving to more complicated examples, things get more interesting. Since the jit has full runtime information, it can do optimizations that a AOT compiler cannot do. At the same time, the lack of a type system does hurt, as you point out. At the moment, tracemonkey handles this by doing type inference and then if it turns out to be wrong (e.g. the type changes) bailing out and falling back on the interpreter. Turns out, types don't change much.
The real issue for a real-world Javascript program is that most of them touch the DOM too, not just execute JS. And right now tracemonkey doesn't speed that up at all. In fact, it can't jit parts of the code that touch the DOM. Eventually the hope is to add that ability.
Re: (Score:3, Insightful)
So basically you suggest doing the exact opposite of what has been shown experimentally to work very in the article?
Re: (Score:2)
As I understand it, in this case tracing basically means converting the specific javascript path that is executed to compiled machine code, as it is run.
So if you're iterating through a loop a thousand times, you run it once as interpreted javascript, generate and cache a machine language version of the javascript you just ran, and run that version 999 times.
The basic concept isn't that new. Intel even had something similar implemented in hardware called a trace cache on the Pentium4 (I don't recall it bei
Re:As fast as C code??? (Score:5, Insightful)
It's kind of a non-sensical concept because Javascript as a language is capable of things C can't do, like eval new code at run time, modify existing types etc.
By the time you have a fair comparison (ie. written C code that can really do everything Javascript can), you have basically written Javascript itself in C. So all these comparisons are really just based on getting subsets of Javascript where it is really doing no more than plain C can do to run as fast as similar plain C, and guess what, that is done more or less by compiling said Javascript to native code.
I find it amusing that all these higher level languages (everything from Java, to Javascript to Python or VB) continuously promote how they are "nearly as fast as plain C now" but then a release or two rolls by and voila they suddenly announce they have improved performance by 10x or some similar metric. But when you ask the question, "oh, so are you 10x as fast as C now?", the reply will be "oh, no, but we're nearly as fast as C!"
Re: (Score:3, Interesting)
Damn. This is going to undo my mods in this discussion.
Unfortunately your argument has a hole in it at this point. I was just about to mod your earlier posts insightful but I thought I'd correct you instead. If you write your JIT compiler in C then it takes the Javascript as input and outputs native code. This glosses over the interactive nature of the JIT compiler but is largely true. The compiler does not execute code in the language that it is written in. It executes code in the language that it is emitt
Re:As fast as C code??? (Score:5, Insightful)
Concurrency is another big win for interpreted (and to jit-ted code like Java) code. The compiler on the target machine gets to decide how to optimize the the code based on the number of processors.
So, _eventually_ C may be slower than JS/Python/Java. :)
And of course, as other pointed out the article says that JS is now getting compiled.
Re:As fast as C code??? (Score:4, Interesting)
Concurrency is another big win for interpreted (and to jit-ted code like Java) code. The compiler on the target machine gets to decide how to optimize the the code based on the number of processors.
Which would be great, if only someone had invented algorithms that could take advantage of that in cases other than trivial parallelisation where the more cores the better. Unfortunately, understanding of how to do that is still in its infancy even in academia, which means that the combination of old fashioned compilation plus moderate run-time adjustments are still likely to blow away anything interpreted for a while to come, and JIT compilation is no big advantage yet either.
Re: (Score:3, Interesting)
Programming functional style (and limiting side effects) makes this task easier.
Programming functional style (and NO side effects) makes this task easier. With multi-threaded apps, its an all-or-nothing approach. Some side-effects will ruin your week in a difficult to reproduce (let alone debug) way.
Even then, I think you'll find its next to impossible to achieve without programmer hints to the compiler, but then you might as well make those hints into thread features of the language and let the programmer
Re:As fast as C code??? (Score:4, Informative)
Java ByteCode is NOT equal to C in speed in the real world. C# applications are NOT equal to C in speed in the real world. For that matter, C++ isn't even equal to C speed in the real world (although the margin is very slim if both are optimized correctly and C++ will work most anywhere that asm shouldn't be used IMHO).
That said, speed is not normally the most critical thing in an application. All of the above mentioned languages have strengths of their own and perform well when used properly.
Re: (Score:3, Informative)
It's not that simple. A native compiler can do profiling as part of the compilation, and spend quite a bit of time on branch prediction and other time consuming optimizations. Five seconds
Re:As fast as C code??? (Score:4, Informative)
Another loss is the lack of link time optimizations. Two identical static functions can not be identified and merged.
Sure they can. The JVM can calculate a hash of each method's code as it loads classes, then change constant pool entries to point to the canonical version of the merged method.
Nor can the functions be reordered to avoid page switching.
Sure they can. The code is just data and the JVM already does heap compacting.
Nor can virtual address mapping be done ahead of time (like SGI's requickstart and Linux' simpler prelink).
Why would you want to do that? As I understand, the more choices you can defer until you have "boots on the ground", the better.
Re: (Score:2, Insightful)
Re: (Score:2)
Or you could just install Linux for them and save all the hassle. :)
Re: (Score:3, Interesting)
Comment removed (Score:5, Insightful)
Re: (Score:2, Insightful)
Precursor to more of Firefox being in JS (Score:5, Insightful)
Re:Precursor to more of Firefox being in JS (Score:5, Insightful)
Javascript, especially when tied to a full featured framework such as ExtJS, is actually freagin cool. Add some IDE support, like in Visual Studio 2008, or in Aptana, and you've got one rock solid, multi purpose dynamic language that is already mainstream and well supported.
Not as cool as Groovy, and I'm a static typing fan myself, but thats the next best thing.
Re: (Score:2)
Also, I was actually wondering about this top
Re:Precursor to more of Firefox being in JS (Score:5, Funny)
Gecko *is* a full-featured framework.
ExtJS is for the more restricted web stuff without code signing.
But then, the parent probably doesn't even know what a prototype is or a closure.
Reading your first two sentences, I found your post informative and worthwhile. But, with the last sentence, the voice reading your comment in my head suddenly turned into that whiny, high-pitched geek voice they use on cartoons.
Re: (Score:2)
Firefox is already written in XUL, which is heavily based on web technologies. If Firefox uses CSS for themes then I see no reason not to increase the usage of JavaScript in the application.
Afterall, Firefox developers probably aren't the most 1337 C/C++ coders out there, but they are probably amongst the best JavaScript ones.
Re: (Score:3, Informative)
Re: (Score:3, Informative)
JS drives most of GUI interaction in FF. The bulk of the C++ is down in gecko, for rendering speed.
Re: (Score:3, Insightful)
Re: (Score:2)
My post was really more about generating discussion though, because I'm genuinely curious about this. I don't have enough JS experience to really say more than it feels awkward to me. I kind of expect things to work
Re: (Score:3, Interesting)
And most of that core stuff is written in C++. Well, actually, its written in an obscure dialect of C++, developed when Netscape ran on a dozen various platforms, with mutually incomparable cpp compilers.
Bu
Re: (Score:2)
Re: (Score:3, Interesting)
'actually, its written in an obscure dialect of C++, developed when Netscape ran on a dozen various platforms'
Really? I was under the impression that the core of Firefox 1.0 was a complete rewrite because the developers determined that the old Netscape stuff was a mess that wasn't worth moving forward with.
Re: (Score:2)
Or program the Windows OS in .net?
Re: (Score:2)
Re: (Score:3, Insightful)
Interestingly, one of the linked blogs talks about how this could lead to more of Firefox being written in Javascript. I haven't done much non-web related Javascript programming, and I haven't really used those new frameworks, but it seems to me like application programming in Javascript is like trying to hammer a nail with the handle of a screwdriver. Sure, it might work, but there are much better tools for the job. What do you guys think?
Why do you think Javascript is so unsuitable? I've done a fair bit of application programming in Javascript and it's fine so long as you keep your code structured (so no different to Perl or even C in that regard).
Premature optimization.... (Score:3, Insightful)
Now if we can just stop all the xss. Now it's just xss 20-40 times faster (in certain contexts).
Actually, if JS gets fast enough, it could rival Flash [slashdot.org]. This is a good thing.
Re:Premature optimization.... (Score:5, Funny)
Considering how long Javascript has been out, and that javascript intensive applications are clearly there in the present, I don't think this is premature =P Its late!
Re: (Score:2)
Javascript is great for all intensive purposes on the web.
Re: (Score:2)
Re:Premature optimization.... (Score:5, Informative)
intensive purposes
"Intents and purposes." Somewhere, an English teacher cries.
Re: (Score:3, Funny)
Somewhere, a comedian cries. Not sure if it's from your missing it or the original joke.
Re: (Score:2)
In order to COMPETE with flash, you need to do more. Like stupid simple multimedia.
Flash is not just a language - it is a rich media application framework.
And lets not forget that you would need to make javascript fast on IE. Good luck with that...
Re:Premature optimization.... (Score:4, Informative)
Like stupid simple multimedia.
like SVG, <canvas> <audio> and <video>
Re: (Score:3, Informative)
No, Donald Knuth, Structured Programming with go to Statements, ACM Computing Surveys, Vol 6, No. 4, Dec. 1974 (p.268). (Unless you can find a reference for Hoare having said it. See here [wordpress.com].)
So super boosted JavaScript + NoScript.... (Score:2)
No (Score:5, Insightful)
And stay off the chans.
Yeah.. but... (Score:2, Funny)
Will it make my Sony Bluray player take less than 10 minutes to boot and play a disc?
Not bad (Score:5, Insightful)
Firefox 3 already gave quite a nice performance boost to Javascript, enough to actually impress me (google maps is a great demonstration of this). It's good to see they haven't stopped there and are busy improving it further, a lot of software developers tend to spend too much time on making new features and not enough time fixing/optimising the existing one, but I think after the backlash from FF2's memory usage, Mozilla has rethought their priorities and I'm glad to say they're doing things right.
Re: (Score:3, Insightful)
Oh no! (Score:4, Funny)
What does the scouter say about its power level?!
Dr. Michael Franz (Score:5, Interesting)
The theories behind tracing optimization were pioneered by Dr. Michael Franz and Dr. Andreas Gal, research scientists at the University of California, Irvine.
Hey that's my old compilers professor and my school!
This PDF [uci.edu] looks like the paper the article is referencing.
Performance is great and all (Score:5, Interesting)
I've written my share of JS-heavy apps and the boost will be nice for that. However, my complaints with JS don't lie with performance.
I think that's enough. I'm sure you could easily argue back but this is my rant about why this boost is not the saving grace to JavaScript.
Basically my point is that performance does not bring JS up another tier. It just prolongs the pain of having a grossly inadequate language for rich application development. JS does have some nice things about it (first-class functions, closures, for(..in..), etc.) but in no way would I consider it "good" for application development.
Step back and realize the movement is pushing applications into the browser. Yes, the same apps that currently use threading; the same apps that have more than 4 input widgets (input, select, radio, checkbox); the same apps that run slow even when written in native code; the same apps that depends on libraries of code; etc. JavaScript, as is, is not The Answer and this performance boost is just a Bluepill [wikipedia.org] in disguise.
Re: (Score:3, Insightful)
Step back and realize the movement is pushing applications into the browser. Yes, the same apps that currently use threading; the same apps that have more than 4 input widgets (input, select, radio, checkbox); the same apps that run slow even when written in native code; the same apps that depends on libraries of code; etc. JavaScript, as is, is not The Answer
Then what technology is The Answer on a platform where native code must be digitally signed by someone other than the user but JavaScript code need not be? Examples of such platforms include PSP, PS3, Wii, iPhone, and some enterprise installations of Windows.
Re: (Score:3, Informative)
At least IE natively will let you debug JS!
That's the first I've heard of that. In order to debug JavaScript you either have to have Office installed, or download the MS Script Debugger. IE does report errors, but their description is horrible. I've found that just the error console in Firefox is much, much better than IE's error reporting. You really should look into Firebug. It's invaluable [ejohn.org]
Re: (Score:3, Insightful)
Wow, you get a gold star for arguing word semantics unnecessarily! (Double bonus for intentionally being flamebait.)
The context of the entire thread, the performance boost, and my comment is that of JavaScript in web apps. My comment was *clearly* about JavaScript in the context of web apps. Hell, my first bullet was that the language and browser are tied too closely together. I guess you read what you want to read.
That said: practically ther
DIGG! (Score:2, Troll)
WHOOPIE!!!
Digg.com will almost be usable now...hehe.
That's pretty impressive... (Score:5, Interesting)
It would nice to see some demos of this with John Resig's Processing.js [ejohn.org]. It could definitely use the kind performance boost being discussed here.
In addition to a performance considerations, it would also be nice to have addtional some additional bit depth in JavaScript.
I anticipate JavaScript will continue to be very popular, but there are alot a lot of reasons other than performance that people won't want to use the language for writing desktop applications over C/C++/Java. That said, there have been alot of recent developments that have made me cautiously optimistic about the future of the language along these lines.
Re: (Score:2)
What does Java have to do with this story?
Re:The Greatest Idea (Score:5, Funny)
Expect this discussion to be full of astroturf, red herrings and trolls
Ah, no problem. Just give the red herring to the troll and he'll let you pass the bridge :)
Re:The Greatest Idea (Score:5, Funny)
I am rubber, you are glue.
Re: (Score:3, Funny)
It won't be just from the Windows side - a good chunk of Linux-heads hate anything but static black text on plain white backgrounds. So this should get interesting...
Goes to show what you know. Real Linux-heads hate anything but static white or green text on plain black backgrounds.
Re:The Greatest Idea (Score:5, Interesting)
Sharepoint 2007 is a good example. Editing of the content is via a browser-based interface, which is quite script heavy. What's interesting is just how script heavy it is. While testing on an old laptop we have connected to an external link, I was a bit dismayed at how slow loading our site was. I got the impression that the browser was pausing before displaying the page for some reason.
Opening up task manager, I saw that before IE displayed the page, it would spin on 50% CPU (on an old hyperthreaded P4) for over 5 seconds before finally rendering the page. After some experimenting which yielded consistent results, I tried Firefox and the difference was dramatic, to say the least.
The upshot of all this is that we may need to recommend to our clients that they use Firefox to edit their Sharepoint 2007 sites, because it provides a significantly better experience than IE does if you have older hardware. On my own desktop at work (a reasonably modern Core 2 Duo) IE does spike the CPU usage, but generally it's for less than a second or two so it's not really distracting. Firefox is faster, but both are quick enough that it doesn't make a real difference to a human.
Completely off-topic: I used refreshes of the task manager process listing to judge how long IE was spinning for. I always assumed the default setting was to refresh the list once per second, and some quick testing now confirms that that is what it does. If you go to View -> Update Speed, the default setting is "Normal". The status tip for this setting says "Updates the display every two seconds". Clearly a lie - or is it? If you select "Normal", then the display does in fact update every two seconds, and there doesn't seem to be any way to get it to go back to refreshing once per second.
Re:The Greatest Idea (Score:4, Interesting)
On the off-topic note: Don't even bother thinking about the task manager, just download the Process Explorer [microsoft.com] and set it to replace the task manager. It's light weight and vastly superior to the task manager in every way. One of the utils I miss in Linux.
Re: (Score:3, Informative)
tip: don't use Task Manager, for investigating performance issues, use PerfMon (under administrative tools on your start menu).
Open a performance report, add the %CPU counter for just IE (it'll be under the Process counter set).
You can get it to update faster than 1 second default, and get it to log to a file instead so you can view it later. Add a network counter and memory counter too for more insight.
Re: (Score:3, Informative)
My wording was wrong - I did understand your paragraph and was merely trying to point that JS could be very helpful when doing SS'ing since it has native Dom parsers and methods. Indeed, there are many things in JS that lend itself well to being able to "read itself" - see Douglas Crockford's comments on JSLint, for instance.
Re: (Score:3, Insightful)
However, I never said that improving JS performance is undesirable. It's the old scripting vs low level programming debate: Low level is faster, but needs more expertise and programmer time. Pick the best tool, etc.
The Mozilla architecture i
Re:Server-Side is still the way to go if you can (Score:4, Insightful)
Doing anything that can be done server-side on the client side is generally a bad idea
Oh, I don't know - what about the simple stuff like form validation? On a high traffic site, receiving a complex form from a client, only to have to send a page back saying "sorry, you forgot this field,do it again" seems to be a waste of both the servers resources and the user's time. Better to just have a JS popup telling them and changing focus to the problem field - no effort on your server's part is needed.
Of course, double-check everything you get at the server, just give the client a chance to sort it out at their end first before troubling you with it.