Why don't they first produce near-Chrome performance for their browser? Every time I use Firefox, it slows down to a snail's pace and eventually crashes if there are more than 4--6 tabs open.
Mozilla can produce near-native performance on the Web
41–50 of 202 posts
Re: Mozilla can produce near-native performance on the Web
#42Earlier quoted context omitted.
The browser vendors definitely do micro-optimize these. DOM binding performance is measured in nanoseconds these days.
Then what is it?
Repaints/reflow. DOM+CSS+JS is a complex system. Watch this: http://www.paulirish.com/2011/dom-html5-css3-performance/
Re: Mozilla can produce near-native performance on the Web
#43Earlier quoted context omitted.
> My understanding is that parsing CSS rules and updating the DOM are incredibly costly operations which none of the browser vendors have yet decided to optimise. These operations are extremely well-optimized. The reason they're slow is that they're also extremely complex and slow operations. It's not something you can hack around.
> The reason they're slow is that they're also extremely complex and slow operations. In that case it seems that we need something new to replace CSS for layout. Or maybe a 'strict mode' equivalent for CSS where styling is separated from layout. In this mode rules that affect style (bold, font etc) cannot affect container dimensions. This mode would include a subset of rules that affect only layout (position, width,…
In this mode rules that affect style (bold, font etc)
But bold and font would affect the width of the text which would affect text flow and possibly affect whether the container ought to grow and shrink or whether it ought to provide scroll bars...
No change is simple, in that sense.
Re: Mozilla can produce near-native performance on the Web
#44Why don't they first produce near-Chrome performance for their browser? Every time I use Firefox, it slows down to a snail's pace and eventually crashes if there are more than 4--6 tabs open.
Is your FF up to date? Since around v20 it feels way snappier than Chrome, at least on OSX.
Re: Mozilla can produce near-native performance on the Web
#45Why don't they first produce near-Chrome performance for their browser? Every time I use Firefox, it slows down to a snail's pace and eventually crashes if there are more than 4--6 tabs open.
Exactly. I don't know how I'm supposed to trust them "making the web faster" when I can't scroll up and down a page.
Re: Mozilla can produce near-native performance on the Web
#46I really disagree with the idea of ASM.js. I think that the whole asm.js thing has got people more people confused into thinking that they can't build fast applications in regular JavaScript.
That is not true. JavaScript code is usually compiled to native code now and is very fast -- generally much faster than Ruby and Python.
I wish Mozilla and other core browser teams would focus on better WebGL support in more drivers and devices as well as better JavaScript engines -- for example Safari especially stands out with their deliberately crippled performance, and Microsoft with their deliberately crippled featureset.
The great thing about the web is convenient APIs like WebGL and nice languages like CoffeeScript. ASM.js negates that for no good reason. There are huge opportunities for exciting WebGL games which don't require the most optimized possible JavaScript, that just haven't been explored yet, and within a couple of years ordinary hardware will go much faster anyway.
Re: Mozilla can produce near-native performance on the Web
#47Earlier quoted context omitted.
> It's just their existing JIT with more information and a few new tricks. Spidermonkey is composed of the Baseline Compiler (JIT) and Ion Monkey (JIT), but a new AOT compiler was written, called "Odin Monkey."
Not really a new compiler. OdinMonkey parses the asm.js type system, but then just passes the information it learned into IonMonkey, the existing SSA-optimizing JIT.
Had to read up on that one! http://en.wikipedia.org/wiki/Static_single_assignment_form
Re: Mozilla can produce near-native performance on the Web
#48Earlier quoted context omitted.
> It's just their existing JIT with more information and a few new tricks. Spidermonkey is composed of the Baseline Compiler (JIT) and Ion Monkey (JIT), but a new AOT compiler was written, called "Odin Monkey."
OdinMonkey uses the existing IonMonkey compiler to do the actual optimization and code generation work. This blog post has more information [0]; see especially the comments section where the author responds to some questions and discusses the relationship between OdinMonkey and regular JS compilation. [0] https://blog.mozilla.org/luke/2013/03/21/asm-js-in-firefox-n...
oh, interesting! Good eye, thanks for pointing this out!
Re: Mozilla can produce near-native performance on the Web
#49BTW, C/C++ code that is compared has multithreading and SIMD capability disabled. In the third page they benchmark asm.js and native with multithreading and SSE enabled. It shows upto 50x slowdown! Not exactly sure what the point of a benchmark without multithreading is. I mean anyone writing performance sensitive apps will use MT right? (given JS is single threaded, it seems this is a dealbreaker). http://cdn.arstec…
Of course single-threaded code will lose to SIMD or threaded code. That's not saying anything surprising. The important thing is to realize that until just recently - a few months or so - people did not believe that SINGLE-threaded JS code on the web could be close to native speed. The Ars article here even has "surprise" in the title when it concludes that in fact that is possible :) So that is a crucial milestone.…
Ok thanks. I guess I'm confused about the gains with asm.js. Looks like it is in the same ballpark performance wise as regular JS (and slower in some cases). So, why would anyone write in a crippled C-like subset of javascript and get normal javascript like performance. In the future if threading and SIMD is standardized, won't regular JS gain performance as well?
Re: Mozilla can produce near-native performance on the Web
#50Earlier quoted context omitted.
Of course single-threaded code will lose to SIMD or threaded code. That's not saying anything surprising. The important thing is to realize that until just recently - a few months or so - people did not believe that SINGLE-threaded JS code on the web could be close to native speed. The Ars article here even has "surprise" in the title when it concludes that in fact that is possible :) So that is a crucial milestone.…
Ok thanks. I guess I'm confused about the gains with asm.js. Looks like it is in the same ballpark performance wise as regular JS (and slower in some cases). So, why would anyone write in a crippled C-like subset of javascript and get normal javascript like performance. In the future if threading and SIMD is standardized, won't regular JS gain performance as well?
No, look again at the numbers - asm.js gets much closer to native speed than normal JS, in many cases, especially large apps. In addition to the numbers in the article, you can see for example,
http://kripken.github.io/mloc_emscripten_talk/#/28
asm.js code makes it easier to get within reach of native performance.