Mozilla can produce near-native performance on the Web • Hacker News Board

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

#91

Post by just2n » Thu, May 23, 2013, 7:38 AM UTC

fhd2 wrote: post #77

just2n wrote: post #65

Earlier quoted context omitted.

Like this? http://jsfiddle.net/eymAS/2/ The DOM is faster than almost everyone believes. It's not 2001 anymore, guys. Web components solve a lot of major problems, but it has little to do with DOM/CSS performance and more to do with encapsulation (ie, so your CSS/HTML/JS don't break a component). DocumentFragments and insertAdjacentHTML solved more performance problems for the DOM than most other API changes have, an…

Here's a version that's not Chrome-only: http://jsfiddle.net/eymAS/21/ I've been wondering why I keep hearing that the DOM is supposed to be slow. Don't people mean to say that rendering (i.e. mostly CSS) is slow? This fiddle is certainly not doing much with the DOM except setting style attributes.

People generally mean their manipulation of DOM is effectively slow. That's a perfectly accurate statement, but the problem is calling the DOM slow as a result. The real culprit is often that doing stupid things with the DOM cause style recalcs, reflows, layouts, compositing, painting, etc. Those are all comparatively expensive.

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

#92

Post by bad_user » Thu, May 23, 2013, 7:39 AM UTC

danbruc wrote: post #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.

That's what asm.js is for, meant as bytecode for compilers.

Take asm.js (e.g. an efficient subset of Javascript), in combination with source maps meant for debugging, and presto, you have everything needed to compile source-code from whatever language you want, including C/C++.

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

#93

Post by just2n » Thu, May 23, 2013, 7:48 AM UTC

krebby wrote: post #74

ChuckMcM wrote: post #69

Earlier quoted context omitted.

Man, that is just scary fast :-)

It should be, it's hardware-accelerated (take a look at the translate3d hack) Paul Irish did a good writeup here: http://www.paulirish.com/2012/why-moving-elements-with-trans...

Yep. Here's a version without using 3d (no layers generated for the followers): http://jsfiddle.net/eymAS/29/

The layout/composition/painting etc is taking roughly 5x longer now. Chrome is smart enough to do it all just once, though, so it's still relatively performant.

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

#94

Post by exDM69 » Thu, May 23, 2013, 7:49 AM UTC

ux-app wrote: post #85

just2n wrote: post #65

Earlier quoted context omitted.

Like this? http://jsfiddle.net/eymAS/2/ The DOM is faster than almost everyone believes. It's not 2001 anymore, guys. Web components solve a lot of major problems, but it has little to do with DOM/CSS performance and more to do with encapsulation (ie, so your CSS/HTML/JS don't break a component). DocumentFragments and insertAdjacentHTML solved more performance problems for the DOM than most other API changes have, an…

That is very cool. I got quite bad rubber banding initially (with a reported 60fps), however after turning off v-sync in chrome://flags I got super smooth 120fps performance. Would be great if Chrome had this option off by default.

> Would be great if Chrome had this option off by default.

Disabling Vsync causes page tearing artifacts (https://en.wikipedia.org/wiki/Page_tearing). It should always be enabled by default. Some new gpu drivers also have "adaptive vsync", where it's enabled by default but gets temporarily disabled when deadlines are not met.

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

#95

Post by riffraff » Thu, May 23, 2013, 7:50 AM UTC

npalli wrote: post #49

azakai wrote: post #29

Earlier 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?

you are not expected to write asm.js, it's to be considered a compiler target (for e.g. emscripten etc)

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

#96

Post by wslh » Thu, May 23, 2013, 7:56 AM UTC

carbocation wrote: post #23

ihsw wrote: post #10

Earlier quoted context omitted.

> What makes web apps feel like swimming through molasses is the DOM. I would contend that network latency and the plethora of domains queried to be a greater impediment to a speedy web. DOM manipulation may be absurdly slow however it cannot hold a candle to latency hold-ups. Most readers on HN live in a quiet and peaceful bubble of high-quality network connections, but the majority of the world is beginning to wake…

Quite a few HNers have probably experienced lossy connections such as Amtrak or busy coffee shops. I would think that those high-loss situations would feel somewhat like a high latency experience.

Lossy mobile connections are very common in the world.

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

#97

Post by fhd2 » Thu, May 23, 2013, 7:58 AM UTC

melling wrote: post #4

What do developers want for a development environment these days? Is C/C++ the next wave of web development? Tooling is a lot better than when I did it 15 years ago. Dart, however, seems like a friendlier environment but it probably won't be as fast a C++(asm.js).

> Is C/C++ the next wave of web development?

asm.js is certainly not targeted at writing web applications in C or C++. It's more about supporting arbitrary languages and getting existing native code bases (e.g. libraries and game engines) on the web.

There's some more background in this presentation: http://kripken.github.io/mloc_emscripten_talk/

(That said, based on anecdotal evidence, C++ seems to work pretty well on large projects where predictability and reliability matter. So for really large, complex web apps, C++ might become a popular choice. Not really seeing this happen though, as web applications generally handle the hard stuff in the backend.)

> Dart, however, seems like a friendlier environment but it probably won't be as fast a C++(asm.js).

It probably doesn't have to most of the time. Hardly anything in the web applications I've worked on was ever CPU-bound, the network is usually the big bottleneck. We're just scripting the browser after all, most of the hard stuff (rendering, storage engines etc.), is already taken care of by native code.

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

#98

Post by Ygg2 » Thu, May 23, 2013, 8:10 AM UTC

jackmaney wrote: post #41

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.

That might be true in your case, but I'm running Firefox 21 smoothly with over 11 tabs open as I type this. And I have a truckload of addons changing my addon bar approximately 12(of 24 installed).

What you are experiencing is definitely abnormal. The only days I have that kind of performance issue is on my old laptop. In which case try switching to Aurora/Nightly, it might help.

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

#99

Post by kybernetikos » Thu, May 23, 2013, 8:11 AM UTC

crabasa wrote: post #35

npalli wrote: post #22

BTW, 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…

Is it fair to describe JS as single-threaded when all modern browsers support web workers? Related: Why does it seem like web workers don't exist? I can hardly think of any popular libraries or web apps that make use of them, despite the seemingly obvious utility.

After getting very excited and doing a bunch of work, we did a lot of performance tests and discovered that for our use case all they did was increase processor load for the same work - the penalty associated with serialising and deserialising things to go across postMessage was greater than the work we were getting done on the other thread.

Of course this was in the early days, and it'd be good to retest it to see if it's better now.

I think that there are a lot of interesting use cases for WebWorkers, but you also have to be aware that for some things they will actually slow down your application.

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

#100

Post by ux-app » Thu, May 23, 2013, 8:13 AM UTC

exDM69 wrote: post #94

ux-app wrote: post #85

Earlier quoted context omitted.

That is very cool. I got quite bad rubber banding initially (with a reported 60fps), however after turning off v-sync in chrome://flags I got super smooth 120fps performance. Would be great if Chrome had this option off by default.

> Would be great if Chrome had this option off by default. Disabling Vsync causes page tearing artifacts ( https://en.wikipedia.org/wiki/Page_tearing ). It should always be enabled by default. Some new gpu drivers also have "adaptive vsync", where it's enabled by default but gets temporarily disabled when deadlines are not met.

isn't tearing preferable to input lag? As I mentioned, with v-sync on there is a very noticeable rubber-banding effect, with it off the result is (perceptually) far smoother.

>It [vsync] should always be enabled by default

Not sure about this. Surely the goal is to maximize perceived performance not 'correctness' (where correctness in this context is defined as each frame being fully drawn before the next one starts).