Mozilla's Servo Engine Is Crazy Fast Compared To Gecko

[Daktyl198]

Samsung engineers work on Servo.

Yeah, but pretty much only to port it to ARM. Most of the heavy work is done by Mozilla or 3rd party developers.

That's good news.

Unfortunately, 4 cores on Android is not that common. On the web when there is high pressure for speed but not for throughput even less?

Activating sleeping core is time & energy consuming process. So either cores are always online or it wont work that well.

Also can we have some JS heavy tests too?

It seems to fit into the current method of Intel/ARM energy savings: Get everything done as fast as possible so the CPU can sit on idle for longer.
Also, Servo currently uses SpiderMonkey (the same JS VM as Gecko) so it would be pointless.

One main difference is that Servo is multi-thread while geko (and firefox in general) is single threaded (which is why if a page locks up, the entire browser locks up ).

You are wrong! (thankfully). Firefox has been multi-threaded for a while, the problem is that it isn't multi-process. The e10s (Electrolysis) project aims to fix this, and so far they're doing an okay job. But at the same time, it's much less stable than the current Firefox, which wouldn't be a problem except ALL of the content is currently rendered on the same process (a separate process from the browser though), so one crashed tab crashes all of the rest, but it doesn't break the browser. They may change that before releasing, but idk.

Servo isn't a JS VM so that would be pretty uniteresting.
The supported way is to pair it with SpiderMonkey but as it uses webkit APIs I guess it would be possible to pait it with V8 as well with some work.

Only if WebKit's Embedding API has anything to do with pairing it with V8, as the Embedding API is the only Webkit API they are using...

[mark45]

The e10s (Electrolysis) project aims to fix this, and so far they're doing an okay job.

Forget Electrolysis, it was started a long time ago. It'll likely be killed by Servo.

[stqn]

Firefox is awfully slow on my Atom netbook, it?s too bad they?re not considering replacing gecko for the desktop version. Although I don?t know if it is gecko or something else that is so slow.

[stqn]

You are wrong! (thankfully). Firefox has been multi-threaded for a while, the problem is that it isn't multi-process

No the problem is it is slow and the GUI freezes when a web page decides it should freeze. What?s the point of being multi-threaded if it can?t even avoid that?

[Prescience500]

Firefox is awfully slow on my Atom netbook, it?s too bad they?re not considering replacing gecko for the desktop version. Although I don?t know if it is gecko or something else that is so slow.

If Servo is a big sucess, then they probably will. It's normal for PR to be overly conservative about projects (or even outright deny them) that are still relativley experimental.

[eydee]

"but there's not yet any plans for using Servo to replace Gecko within Firefox or Thunderbird"

Which makes the whole thing completely useless for regular users. Do they expect us to move to mobile devices from our PCs? Microsoft couldn't do it, Mozilla won't be able either. A PC cannot be replaced by mobile devices.

[RahulSundaram]

"but there's not yet any plans for using Servo to replace Gecko within Firefox or Thunderbird"

Which makes the whole thing completely useless for regular users. Do they expect us to move to mobile devices from our PCs? Microsoft couldn't do it, Mozilla won't be able either. A PC cannot be replaced by mobile devices.

Mozilla isn't doing that. They are just limiting their focus to regular users who *do* use mobile devices since that is an easier target for now.

[zanny]

No the problem is it is slow and the GUI freezes when a web page decides it should freeze. What?s the point of being multi-threaded if it can?t even avoid that?

To avoid an application's interface freezing when internal parts lag out you need to have a render loop thread independent of the rest of the application.

For Firefox, that would mean you want at least four threads - the chrome (as in decoration) thread for the browser, running independently of the pages - the page renderer itself, running independently of the JS vm or html engine - and two input threads, one for each of those respective parts, so that you do not have your commands submitted to an internal thread that is lagging out if it is avoidable.

You can have multi-threaded software without a separate render thread. But the most user-facing benefit of multi-threading besides stuff being done faster is to render independently of your workload threads so the interface never lags.

Qt uses an independent render thread for Qt Quick on everything but Mesa, but example.

[clementl]

Servo isn't a JS VM so that would be pretty uniteresting.
The supported way is to pair it with SpiderMonkey but as it uses webkit APIs I guess it would be possible to pait it with V8 as well with some work.

Firefox already uses SpiderMonkey's successor, IonMonkey.

[balouba]

Servo isn't a JS VM so that would be pretty uniteresting.
The supported way is to pair it with SpiderMonkey but as it uses webkit APIs I guess it would be possible to pait it with V8 as well with some work.

the *monkey engine is faster than v8 at this point anyway