Here a post on Medium from Casper Beyer (@caspervonb) talking about Electron
Electron is Cancer
You Wouldn’t Want to Spread Cancer, Would You?
ah yeah that's a clickbait title alright ...
so the article is not that interesting even if right talking about perf
but what caught my attention is the last paragraph
Electron Is Not Native
I tend to call Electron applications web pages whenever I talk about them, which in turn tends to piss off a lot of web developers but really that’s all they are. There is nothing desktop like about Electron applications, they always feel out of place, even the simplest elements like the native menu bar is not available, it’s usually a custom alien looking thing if it’s even there.
Electron applications just don’t integrate with the operating system the way a native application is expected to do, is this not the reason that why we vowed to kill Flash and the Air Runtime in the first place?
Even stranger, lately there have been projects popping up that compile from C# to Electron. Yes, let that sink in, from native code (C# can be AOT compiled to native, has tons of GUI frameworks) to JavaScript, so that it can run as a webpage in the Electron browser.
I do not even…
Either this guy does not know Adobe AIR or we have a widely different view on what is OS integration.
Yeah it kind of pisses me off because it is unfair to the AIR technology, and that's not the first time I see this kind of "logic".
eg. if an AIR app work like shit oh it is automatically because AIR is based on Flash, not because the dev did a bad job or because the app is super old and never got updated etc.
I see that all the time, yadda yadda yadda this AIR app is shit because it does not support retina display on my mac, and yet AIR support retina display but the dev who published the app did not support it and/or published the app so many years before the feature was supported and never bothered updating the app.
I saw that a lot around AIR v1.0, how much it was eating too much memory, how much this or that, everyone was criticising the tech for petty stuff; and worst, those stuff got fixed on next and next versions, but still 10 years later the same guys bring back the same arguments against AIR from v1 while AIR is now v28.
AIR as a technology, while not being completely and truly native, beat the crap out of Electron and can run circles around it in term of performance.
But it is always the same problem, dev think that using a particular tech will magically solve their problem, if anything bad happen, like bugs or perf problems ... oh oh it's the tech that is bad, never ever those same dev will think that maybe their code is the source of the problem.
Like this guy recently on another forum, here yet again another clickbait title
I'm forced to leave Adobe AIR due compatibility issues and AIR SDK bugs
Oh you're forced to leave AIR? but then leave AIR you freaking moron!
It's not the fault of the tech if you don't know how to debug/fix/improve the perf of the app you wrote yourself, that's your fucking responsibility.
The very same guy would have exactly the same problems with any other tech, but hey it's so convenient to criticise the tech than to admit that maybe your code is not perfect and need probably some more work.
Always the same story, dev work on an app, never bother to test for perf, add features after features after features, still never bother to test for perf, then release the app, then realise perf is not what was expected and then complain.
There are no excuses, a little google search of 2mn for "Adobe AIR performance" reveal major ressources
I already talked about that some time ago in Memory and Performance.
Like Oliver Goldman explains it very well in his post
Application performance is perennial. It's in its nature. In order for an application to perform well, every part of the application has to perform well. Lapse in one area and it brings your entire application down. It's difficult to write a large application without letting your guard down once in a while.
Questions about performance often indicate a failure to understand this weakest-link-in-the-chain aspect of the problem. Here are some of my favorite lousy questions about performance and AIR applications:
- Will my AIR application be fast?
- Is AIR fast enough to do X?
- Isn't AIR too slow to do Y?
(Here's proof also that no matter what your kindergarten teacher told you, there is such a thing as a lousy question.)
AIR almost never makes it impossible to achieve good performance in your application. On the other hand, AIR can't do it for you, either. Like I said, it's the nature of the problem.
Fortunately, standard tuning techniques apply to AIR as much as they'd apply to writing any piece of desktop software.
It is a must read and you should read it before building any new AIR app.
If performance is your main complain, then you have to measure perf right from the start and you have to measure perf all the time, again and again and again, and yes it does require constant works and it's something hard to achieve.
Not only with AIR, but with any tech.
Now, coming back to Electron and comparing to AIR, how come did I say that AIR can beat the crap out of any Electron app ?
It's very simple: the rendering engine is Flash, not a full blown browser.
But wait ..., I did not say that it was faster and here a little something to think about when it come to perf.
It is Space vs Time.
A space–time or time–memory trade-off in computer science is a case where an algorithm or program trades increased space usage with decreased time. Here, space refers to the data storage consumed in performing a given task (RAM, HDD, etc), and time refers to the time consumed in performing a given task (computation time or response time).
What do you try to optimize for?
Space (RAM, HDD storage, etc.) ?
or
Time (CPU cycles, I/O, etc.) ?
displaying something using the less possibles resources?
or
displaying something smooth on screen without any freeze?
That's not the same thing!
And most of the time you can not have both, you will have to make a trade off.
The main criticism you will see against something like Electron is that it will eat up your RAM like nothing else, like Chrome, and that's normal because it is based on the Chromium Embedded Framework (CEF).
So when I say that AIR can run circles around something like Electron, I do mean you can build an AIR app that use much less RAM (quite ironic compared to the AIR v1.0 criticism).
But I do not say that AIR is faster than a browser rendering engine like Chrome, well ... not by default and not for everything.
If you have a single line of text, for example: "Hello the big world", AIR will probably display the text a bit slower than CEF (even if not noticeable), but the huge difference is how much RAM will be used to display that line of text.
Now, if you have a huge amount of text to display, like few hundred of pages (think something like wikipedia), well ... it will take more work with AIR to keep using that less RAM and things like scrolling text etc. will feel slow (by default), while within CEF the display will stay fast and the amount of RAM will stay consistant even if huge.
Also why it is very useful to have an HTMLLoader or StageWebView in AIR, for such case where you do need to display a hell lot of text and so a browser engine come handy to do just that.
And also why you do plan the measurement of your performances depending on where it matters for the app and the users supposed to use that app.
And finally, also why I can allow myself to curse against a dev and call him a moron to not have done his job (eg. measuring performance).
So let's analyse where the mistakes are made
It's not a matter of performance or optimization as when a player can play the game 60FPS they can have it running in very old machines, and some others having very powerful rigs can't run it smooth.
I have some angry customers complaining the game is not well optimized when I know it's a matter of driver/OS compatibilities.
Wrong, it is a performance problem.
The guy is just assuming but have no idea of whats going on, and yet he is assuming it wrong.
And so from there it continues
Sometimes the game locks to into 30FPS for not apparent reason. But I've managed to replicate some slow frames with some of this events, but they don't appear always.
- opened youtube sessions playing stuff.
- opening skype in another screen.
- having the game in one specific screen (I have two monitors).
oh a game drop from 60FPS to 30FPS ? well I'm pretty sure where the problem happen now
but the guy assumptions are still completely wrong, well... if I open skype on another screen let's see if it fixes stuff... why no try giving a good kick to the computer while you're at it, sometimes it fixes thing too
and it goes to
I no longer display the message so much, I let them play with low FPS now. It's bad but the only solution I am left!
here!! that's the mistake!!!
Not all your players will have the exact same hardware, you can not expect everyone to run at 60FPS, a PC is not a console.
Focusing that much on the 60FPS for about 10% of players is ridiculous, but the asumption made are even worst, so I will have one word to explain the problem: VSYNC.
and here you can find a pretty good explanation on vsync
How VSync works, and why people loathe it
in particular
Essentially this means that with double-buffered VSync, the framerate can only be equal to a discrete set of values equal to Refresh / N where N is some positive integer. That means if you're talking about 60Hz refresh rate, the only framerates you can get are 60, 30, 20, 15, 12, 10, etc etc. You can see the big gap between 60 and 30 there. Any framerate between 60 and 30 your video card would normally put out would get dropped to 30.
Now maybe you can see why people loathe it. Let's go back to the original example. You're playing your favorite game at 75Hz refresh and 100FPS. You turn VSync on, and the game limits you to 75FPS. No problem, right? Fixed the tearing issue, it looks better. You get to an area that's particularly graphically intensive, an area that would drop your FPS down to about 60 without VSync. Now your card cannot do the 75FPS it was doing before, and since VSync is on, it has to do the next highest one on the list, which is 37.5FPS. So now your game which was running at 75FPS just halved it's framerate to 37.5 instantly. Whether or not you find 37.5FPS smooth doesn't change the fact that the framerate just cut in half suddenly, which you would notice. This is what people hate about it.
If you're playing a game that has a framerate that routinely stays above your refresh rate, then VSync will generally be a good thing. However if it's a game that moves above and below it, then VSync can become annoying. Even worse, if the game plays at an FPS that is just below the refresh rate (say you get 65FPS most of the time on a refresh rate of 75Hz), the video card will have to settle for putting out much less FPS than it could (37.5FPS in that instance). This second example is where the percieved drop in performance comes in. It looks like VSync just killed your framerate. It did, technically, but it isn't because it's a graphically intensive operation. It's simply the way it works.
but there is more, if you search around about Stage3D and vsync
you find this excellent post from Sergey Gonchar
Stage3D “extended” and optimizations
where we can read
Vsync
Vsync is an optional GPU driver property, which solves the synchronization problem of frame rate with vertical blanking interval of monitor for smooth swapping from back to front(at first we draw to the back buffer and then it swaps to the front). Without Vsync you can get some artifacts, for example, one part of the image is a previous frame and other part is the current frame. This produces a small penalty in latency, because the program has to wait until the video controller has finished transmitting the image to the display before continuing. Triple buffering reduces this latency significantly. But in Stage3D there are no any API to work with buffers and we will find other ways to optimize it.
The GPU only draws frames on a vsync(1/60th of a second). When Flash asks it to draw, it waits for the next vsync. This can be long for two reasons:
- The CPU work per frame is less than 1/60th of a second. In this case the GPU swap time represents “idle” time while we wait for a vsync. This is harmless. This is probably the case for DisplayList apps.
- Flash has its own, separate timer that drives the frame rate, and it can get offset from vsync. Imagine two lights blinking at different frequencies. At first they blink simultaneously, then they gradually drift apart, then they come together again, and then drift apart again. During some phases of this cycle, GPU swap will be small: Flash asks the GPU to draw just before a vsync. During other phases, GPU swap will be big: Flash asks the GPU to draw just after a vsync, and the GPU waits for the next one. This results in periodic dropped frames. Try changing your framerate to 20, 30 and 60.
(thanks to Adam Cath for the explanation)
The Flash/AIR API is already doing its job by using a triple buffering, now the dev need to do his job and what it is?
Well... instead of insisting that everything HAVE TO run at 60FPS all the time, accept that only a percentage of users will be able to run at 60FPS and then allow the users to chose other framerates like 30FPS etc. or simply do not show a warning as soon as it goes under 60FPS.
That's it.
You can change tech how much you want you not gonna change how vsync works.
And that the same for Electron vs Flash/AIR, you have to go with the pros and cons of your tech, it is useless to fight it, eg. the classic chose the tool for the output you want and based on what the app is supposed to do.
The same you will not expect to reach 60FPS with the classic display list, don't expect to not use a lot of RAM if your underlying rendering engine use CEF.
