Ask HN: How to optimize Electron apps? | Hacker News Reader

Ask HN: How to optimize Electron apps?

38 pointsazhenley19 comments

There has been a lot of discussion on performance issues with Electron apps the last few weeks [1-5]. I'm curious what is something that an individual developer could do to optimize their Electron app. Electrino [6,7] is a nice proof of concept that it is possible to greatly reduce the app size. Others have said to share Chromium between apps, but that isn't something that an individual has power over.

So how could Chromium be stripped down to only include the features needed for a given Electron app? Are there other potential optimizations?

[1] https://news.ycombinator.com/item?id=18733837

[2] https://news.ycombinator.com/item?id=18631738

[3] https://news.ycombinator.com/item?id=18578261

[4] https://news.ycombinator.com/item?id=18765482

[5] https://news.ycombinator.com/item?id=18761840

[6] https://news.ycombinator.com/item?id=14260755

[7] https://github.com/pojala/electrino

View on HN

Optimize by ditching Electron and use Qt instead. You will gain ~50% performance increased and ~50% smaller app

What's the TCO difference between Qt and Electron?

Has anyone even measured TCO on Electron apps?

I've certainly considered it, especially since I found out that fman uses Qt and Python: https://www.qt.io/fman-built-with-qt

From my initial tests with Qt, it isn't as convenient as Electron since I already have a fair amount of web dev experience, but maybe it will be worth it in the long run (and for the performance benefits).

Disclaimer: I'm the author.

You can also use .NET with Qt.

https://github.com/qmlnet/qmlnet

With this, you don't need to touch C++. It is still beta, but only because the API may change. It is very stable and has a large test suite.

Qt is >$5,000 whereas Electron is free

Your average Electron app has no need for a commercial Qt license. LGPL is just fine.

I understand that you feel that Electron isn’t worth optimising, and your answer offers up a good alternative to Electron.

However, this is an interesting question in and of itself, and I think it’s worth hearing out the answers. Could be some interesting techniques to pick up and reapply elsewhere.

I feel like optimizing your actual app as it runs in Chromium (Javascript, DOM usage, resources, etc.) is the right approach here.

The Chrome dev tools are superb for measurable insight into this.

App size is one metric, but as long as you’re within a few hundred MB on reasonably modern hardware, that shouldn’t actually be significantly affecting performance in most cases.

Discord is a great example of a complex Electron app that is very performant.

It may be too obvious, but something you can do that a staggering number of electron/CEF/etc devs don’t is to write highly efficient JavaScript. This leads to craziness like the desktop Spotify client eating nearly a whole gigabyte of memory after browsing albums and artists for a minute or two, which is by no means necessary.

Make performance a high priority, don’t just stop once it’s working.

This is often because they use a bunch of third party software that adds a lot of bloat. For example Firefox devtools uses redux and you can notice the perf issues.

Another issue is many js devs don't know how the Jit compilers work. Using classes is usually more efficient than plain js objects if you are doing a lot of mutations.

I remember there being a bug in chrome which causes it to keep loaded images in memory forever, this can cause RAM usage to grow into the gigabytes range but this only affected electron applications. Additionally in a code base as big as chrome it wouldn't surprise me if there are thousands of tiny variants of those bugs that leak a few 100KB of RAM here and there which then add up to 100MB or more even in a sufficiently optimized application.

I think the fundamental problem is that chrome just wasn't built to host a single application that never refreshes. It's optimized for opening dozens of websites and cleaning up resources in between page loads. This requires a certain amount of memory no matter what you do.

In terms of rendering performance there aren't any significant problems if the DOM manipulation is done correctly. It shouldn't be any slower than say Qt assuming properly written JavaScript.

I'm sure a solution can be found to solve those problems. However the sad truth is that no one who chooses electron cares about any of that and would rather point out how cheap RAM is and that you could solve this problem by spending 60€ on another 8GB of RAM.

Got you: http://seenaburns.com/debugging-electron-memory-usage/

Write certain operations (like math- or string-heavy functions) in c and bundle that as a shared library. AFAIK this is what vscode does and why it runs so fast.

Could you point to a resource or a doc? Would it be possible to do something like that but in Go?

I'm not quite sure how it works in javascript, but I would look up javascript cffi or electron cffi or something like that to find how to do it. As for go, it might be possible, but it'll definitely be harder. You'll have to find how to expose a c api to your go code.

You could do it via Node.js native modules.

I write in rust, look into native extension, nodejs

Browsers do have memory leaks, and sandboxed processes without same page merging duplicate a lot.

Web browsers are nice, you can view anything a web browser can display in them.

If it were up to me, I’d just have a local web server, running a reddit clone that refreshes every five seconds.

Reply on news.ycombinator.com