Live data from Hacker News

Mozilla can produce near-native performance on the Web

arstechnica.com

11–20 of 202 posts

Re: Mozilla can produce near-native performance on the Web

#11
post #8
post #7

Earlier quoted context omitted.

> its slightly slower (a few %) than regular JS on browsers without asm.js support You sure you meant what you said here?

[deleted]

Grandparent may be saying that, but that's not true.

The comparison that is close is code produced from a C compiler for normal JS, versus code produced from the same compiler and code for asm.js. BUT code that would be written by a human would be expected to be more compact and run much faster than either of those.

Furthermore the code that they wrote would not run on all browsers, and if it did run often crashed the browser. Human written code would not have those problems.

Re: Mozilla can produce near-native performance on the Web

#12
post #5

For most applications JS doesn't need to get any quicker. What makes web apps feel like swimming through molasses is the DOM. Even something as simple as getting a Div to follow the mouse on anything but the simplest of pages is impossible to do without incurring ridiculous lag. I don't know enough about them, but it seems that maybe Web Components may offer some answers by encapsulating mini Document trees which pre…

What makes web apps feel like swimming through molasses is the DOM.

In my experience, it's the lack of threading. Or any way to perform an operation without affecting the UI. Web Workers go a long way to solving this, but they're limited in what they can do.

Re: Mozilla can produce near-native performance on the Web

#13
post #7
post #6

tl;dr: its not as fast as native but its much better than AT expected, and actually within 2x the speed of native. Also its slightly slower (a few %) than regular JS on browsers without asm.js support.

> its slightly slower (a few %) than regular JS on browsers without asm.js support You sure you meant what you said here?

Check this out (from the asm.js spec)

    function add1(x) {
        x = x|0; // x : int
        return (x+1)|0;
    }
This declares x to be an int in asm.js, which allows a bunch of optimizations. In a non-asm.js engine, it is an extra 2 operations.

It's not difficult to believe that a non-asm.js engine would be slower with the type annotations than without, although I don't have any performance numbers to check.

Re: Mozilla can produce near-native performance on the Web

#14
It seems Mozilla and Google are moving more and more toward their own browser specifications and mechanisms. Microsoft and Netscape did this in the 90s, and it ended up causing nothing but pain.

Optimizing JS is interesting, but creating browser-specific applications of code meant for a web audience disturbs me. I don't want a repeat of the first browser wars. Hopefully Mozilla will work toward w3 standards in this effort, since Google clearly hasn't with Dart.

Re: Mozilla can produce near-native performance on the Web

#15
post #5

For most applications JS doesn't need to get any quicker. What makes web apps feel like swimming through molasses is the DOM. Even something as simple as getting a Div to follow the mouse on anything but the simplest of pages is impossible to do without incurring ridiculous lag. I don't know enough about them, but it seems that maybe Web Components may offer some answers by encapsulating mini Document trees which pre…

For most applications, the Dom is the weak point because manipulating the Dom is as ambitious as the apps get. The exciting part of asm.js is not that it can speed up existing apps, it's all the cool new things you can do on the client side now that were simply to slow to be possible before.

Re: Mozilla can produce near-native performance on the Web

#16
post #11
post #8

Earlier quoted context omitted.

[deleted]

Grandparent may be saying that, but that's not true. The comparison that is close is code produced from a C compiler for normal JS, versus code produced from the same compiler and code for asm.js. BUT code that would be written by a human would be expected to be more compact and run much faster than either of those. Furthermore the code that they wrote would not run on all browsers, and if it did run often crashed th…

Thanks for pointing out my error.

(Hope you don't mind that I deleted my comment.)

Re: Mozilla can produce near-native performance on the Web

#17
post #12
post #5

For most applications JS doesn't need to get any quicker. What makes web apps feel like swimming through molasses is the DOM. Even something as simple as getting a Div to follow the mouse on anything but the simplest of pages is impossible to do without incurring ridiculous lag. I don't know enough about them, but it seems that maybe Web Components may offer some answers by encapsulating mini Document trees which pre…

What makes web apps feel like swimming through molasses is the DOM. In my experience, it's the lack of threading. Or any way to perform an operation without affecting the UI. Web Workers go a long way to solving this, but they're limited in what they can do.

Not sure I agree with this. Very few web applications are CPU bound to the point of locking the UI. Web Workers are extremely useful, however very few current web apps benefit from them. Given they cannot interact with the DOM they are limited to pure number crunching. Great if you're ray tracing or encoding/decoding sound or video, not much use to the other 99% of web apps.

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.

Re: Mozilla can produce near-native performance on the Web

#18
post #17
post #12

Earlier quoted context omitted.

What makes web apps feel like swimming through molasses is the DOM. In my experience, it's the lack of threading. Or any way to perform an operation without affecting the UI. Web Workers go a long way to solving this, but they're limited in what they can do.

Not sure I agree with this. Very few web applications are CPU bound to the point of locking the UI. Web Workers are extremely useful, however very few current web apps benefit from them. Given they cannot interact with the DOM they are limited to pure number crunching. Great if you're ray tracing or encoding/decoding sound or video, not much use to the other 99% of web apps. My understanding is that parsing CSS rules…

> 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.

Re: Mozilla can produce near-native performance on the Web

#19
post #17
post #12

Earlier quoted context omitted.

What makes web apps feel like swimming through molasses is the DOM. In my experience, it's the lack of threading. Or any way to perform an operation without affecting the UI. Web Workers go a long way to solving this, but they're limited in what they can do.

Not sure I agree with this. Very few web applications are CPU bound to the point of locking the UI. Web Workers are extremely useful, however very few current web apps benefit from them. Given they cannot interact with the DOM they are limited to pure number crunching. Great if you're ray tracing or encoding/decoding sound or video, not much use to the other 99% of web apps. My understanding is that parsing CSS rules…

The browser vendors definitely do micro-optimize these. DOM binding performance is measured in nanoseconds these days.

Re: Mozilla can produce near-native performance on the Web

#20
I would much prefer having a sane new language replacing JavaScript instead of this hack to improve performance. A new language could provide the same performance advantage and make writing web applications much more pleasant.

Admittedly it is harder to introduce a new language across all (major) browser but I think it would really be worth it.

Post reply on HN