Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A new speed milestone for Chrome

blog.chromium.org

Post reply on HN
Print view View original

71–80 of 161 posts

Re: A new speed milestone for Chrome

#71

Post by omnimike »

codedokode wrote: post #62

I think that browser developers are optimizing the wrong thing. Specifically: they optimize for execution speed while they better optimize for minimum memory usage instead. Let me explain why this is more important. Let's say I am visiting a properly made website and it takes 10% of CPU to render. Even if browser devs make their browser twice faster, it will only save 5% of CPU time - and that would be completely unn…

The reason for the focus on CPU time is that it has the larger impact on battery life.

Re: A new speed milestone for Chrome

#72

Post by [deleted] »

mort96 wrote: post #67
jart wrote: post #40

Earlier quoted context omitted.

Here's a conundrum. Fabrice Bellard's QuickJS engine takes 3 minutes to run the test262 ECMAScript conformance suite. d8 takes 37 minutes to run test262 according to https://medium.com/compilers/testing-the-v8-javascript-engin... and it crashes for me in Chrome https://v8.github.io/test262/website/default.html Has anyone else observed this performance disparity? Could it really be possible that a JavaScript engine wr…

I wrote a small lisp in Rust. I try to not do obviously stupid things, but it's just a basic parser + AST interpreter; its execution speed is slow compared to even a basic bytecode interpreter, and it's absurdly slow compared to a JIT. Yet it runs hello world in a fraction of a millisecond, whereas V8 needs tens of milliseconds. In executing one computationally intensive program, V8 would be many orders of magnitude…

[deleted]

Re: A new speed milestone for Chrome

#73

Post by ggreg84 »

codedokode wrote: post #62

I think that browser developers are optimizing the wrong thing. Specifically: they optimize for execution speed while they better optimize for minimum memory usage instead. Let me explain why this is more important. Let's say I am visiting a properly made website and it takes 10% of CPU to render. Even if browser devs make their browser twice faster, it will only save 5% of CPU time - and that would be completely unn…

> Optimizing for speed usually causes increased memory consumption,

Lol, no?

If your benchmark is memory bound, reducing memory usage is probably the simplest way to make it faster.

Re: A new speed milestone for Chrome

#74

Post by pwdisswordfish9 »

stock_toaster wrote: post #43
jart wrote: post #40

Earlier quoted context omitted.

Here's a conundrum. Fabrice Bellard's QuickJS engine takes 3 minutes to run the test262 ECMAScript conformance suite. d8 takes 37 minutes to run test262 according to https://medium.com/compilers/testing-the-v8-javascript-engin... and it crashes for me in Chrome https://v8.github.io/test262/website/default.html Has anyone else observed this performance disparity? Could it really be possible that a JavaScript engine wr…

I think Fabrice Bellard (ffmpeg, qemu, Bellard's formula, quickjs, tinygl, tinycc), could _already_ be considered the Han Solo of programmers.

Fabrice shot first!

Re: A new speed milestone for Chrome

#75

Post by oxplot »

codedokode wrote: post #62

I think that browser developers are optimizing the wrong thing. Specifically: they optimize for execution speed while they better optimize for minimum memory usage instead. Let me explain why this is more important. Let's say I am visiting a properly made website and it takes 10% of CPU to render. Even if browser devs make their browser twice faster, it will only save 5% of CPU time - and that would be completely unn…

If you improve CPU performance, you can compress memory with the leftover cycles. This is what I do on my RPi which allows me to run quite a few memory hungry processes at the cost of some CPU (which is fine, because those processes are mostly idle).

Re: A new speed milestone for Chrome

#79

Post by IshKebab »

austincheney wrote: post #60
greggman3 wrote: post #17

There are certainly lots of situations where one browser beats another For example in this microbenchmark, Chrome is 10x slower than both FF and Safari at one method. https://jsbenchit.org/?src=cfcb916dd03df45952183e6484a14344 Here's another where in one case Firefox is 54x faster than Chrome https://jsbenchit.org/?src=beb26575ad78caa99a2a8c45ce2b780f

https://jsbench.github.io/#b39045cacae8d8c4a3ec044e538533dc Look at DOM performance. Chrome has a ceiling of about 45m ops/s where FF max speed is dependent upon your ram and bus speed reaching beyond 4-5b ops/s. In both though querySelectors perform at about the same speeds as slow as 25000 ops/s. I have written an OS GUI that executes in the browser. It loads, including full state restoration in about 120ms. I was…

I suspect that isn't why you weren't hired.

Re: A new speed milestone for Chrome

#80

Post by jansan »

V8 is an absolute marvel of engineering. The performance gains are very impressive.

But Chrome still has some work to do on rendering performance. The switch to hardware acceleration was actually a deceleration for quite a few cases. For example rendering very large concave SVG paths is probably 10x faster on Firefox compared to Chrome. I hope to see some effort in future to improve this, too.

Post reply on HN