Hacker News Reader

Comment by nvrspyx | Hacker News Reader

A third-option that I would like to see is extending the latter to an Electron alternative (aka using Servo as a cross-platform GUI). There's definitely positives to Electron, but it would be nice to see a more performant, less memory hungry, and more battery friendly alternative.

View on HN

Servo last time I checked used the same if not more memory (100MB) for basic pages. There doesn't appear to be major differences for that application yet.

Why should there be any great difference? Firefox is already written in a language where compilers have been optimized since decades.

Rust will not bring that magic.

Rust makes it much easier to do complex performance optimizations safely, particularly those involving concurrency. The canonical example is the multi-threading of Servo’s CSS processor.

It’s not an automatic magic bullet, but in a world where humans are still writing the code, Rust’s feature set makes many performance optimizations much more practical.

When did Firefox last crash on you? Aren't we optimzing on a problem which is practically non-existing?

Rust isn't what can bring that "magic", but a rewrite sure can.

Why, better lifetimes' control could reduce the RSS, and reduce the GC time / energy.

(Provided that the C++ version is not strictly optimal WRT resource allocation; I think it's a rather safe bet.)

Hypothetically there should be possibilities for significant memory reduction by being able to deploy only what you need from the runtime instead of having everything loaded at once.

The memory usage part isn't really apart of rust or C, but rather that projects like chromium require significant hoops to jump through if you wanted to compile electron with only what you need.

I expect that servo will be tackling this issue, the browser works standalone and that's a hefty achievement in itself.

I'm not personally a rust zealot, but I know that rust builds on LLVM and therefore benefits from some of that very same engineering effort that was built to optimize C and C++.

Clang usually has worse performance than GCC.

Is there anything specific GCC does for performance that Clang/LLVM could adopt? How is this race expected to evolve over time?

it's not so much that gcc does anything specific so much as LLVM is just really really inefficient—they don't track compilation time at all so it's easy for releases to regress, half the stuff in there is academics implementing their PhD thesis aiming for algorithmic accuracy with little regard for efficiency, and LLVM's design itself is somewhat inefficient (multiple IRs, lots and lots of pointers in IR representation, etc)

that said this makes it an excellent testbed but compilation time will keep getting slower every release until they start caring about it

The rust compiler team now tracks LLVM performance, see [0]. They are able to spot regressions as soon as they get merged, and petition to get the change reverted or performance fixed when the impact is large. This has been fairly successful so far, but obviously needs sustained efforts if we are to ever dream of ever getting halfway decent compilation times.

[0]: https://nikic.github.io/2020/05/10/Make-LLVM-fast-again.html

Not answering your question but in my experience reading assembly output of the two compilers the unoptimized output of Clang is atrocious while GCC is closer of what a human could have wrote. Clang seems to have to do better in optimization passes to archive similar results. Usually Clang was a faster compiler in O1 but I don’t think it’s true anymore.

that's just because gcc has certain optimization passes that can't be disabled

(that said gcc -O0 is still absolutely nothing like what a human would write)

Has anyone tried Cobalt? It looks like something based on it could be an alternative to Electron.

https://cobalt.foo/

It's meant for embedded but that probably just means it's easy to build and uses low memory.

A high-performance, small-footprint platform that implements a subset of HTML5/CSS/JS to run applications, including the YouTube TV app.

Cobalt lags on modern web APIs pretty badly. I wouldn't recommend it.

Can you elaborate on that?

To be clear I wasn't suggesting that Cobalt is a replacement for Electron. Electronic has a lot of its own APIs too.

Rather, I wonder if Cobalt could be better than Servo along some dimensions as an engine for something like Electron.

I wonder if they could also adapt into a game UI framework; design fast, cross platform, scalable game HUDs with HTML/JS.

I’ve posed this question several times online and in the Servo repo and the response was always, “Umm, no, not interested.”

The alternative exists since 20 years now, run a background daemon with local browser, or ping back in the platform WebWidgets.

Reply on news.ycombinator.com