150 MB RSS of a single worker process (out of typically 4+)? Did the dude at least try running `free -h` before and after starting any Electron application? Multiple that by at least 5 and you're somewhat closer to the truth.
But seriously -- wine should have equal performance to running a program "natively" on windows because it essentially is running the program natively, just with different system DLLs that call back to the linux kernel instead of the NT executive.
Their implementation may be slightly slower in places, but it's not a problem inherent to Wine itself, and could always be fixed.
I know there's a stigma against running win32 apps on linux, and possibly rightly so, but there really isn't a reason why Wine couldn't be a legitimate runtime environment for linux. You can make 100% open source software that targets Wine, and never needs to use or link to proprietary software.
Wine has even been ported to architectures where there have never been native windows ports, like the ppc64le port of Wine.
(Wine/win32's binary interface is also easier to intercept and automatically translate/emulate calls for non-native architectures, which is the basis of WoW64 and x86 on ARM emulation, and in Wine land, projects like Hangover https://github.com/AndreRH/hangover )
> wine should have equal performance to running a program "natively" on windows
That is not guaranteed. Windows programs and Win32 APIs are writting for and optimized to run on the the NT kernel which has different perfomance characteristics from the Linux kernel. Some example:
- Wine needs to emulate a case-insensitive filesystem on top of a case sensitive filesystem, which is less efficient thatn using a filesystem / kernel FS layer that is designed for this.
- Some locking primitives are different enough that Linux will need additional syscalls to let Wine reach the same perfomance when emulating the Windows ones [0]
Hmm, the filesystem thing would be a constant slowdown, and there is the locking/async primitives that are generally better on Windows, but at least those are being worked on, both for Wine and Linux in general. I kind of recall reading about an option for ext4 to allow optional case insensitive operation? Ah! Recently added it seems. Needs a pretty recent kernel and a format-time config option that I doubt any linux distro is using yet, though [0]
I just meant that, in general, Wine should be very close to as fast on Windows, since it can usually implement win32 DLLs without much emulation/translation needed. Excepting all the bits that do :-)
Now that it is becoming easier to run linux on windows and maybe macos, linux dev should make an effort to guarantee linux apps run REALLY fine on window and mac. That way instead of creating 3 native apps (win, mac and linux), you could simply target linux.
This won't work - developers will always target the biggest platform first and then complain that it takes to much work adapt the program to more portable APIs.
If the app had only essential features, it could have functioned well on web.
Back when Russian Facebook rival vk had an unlimited offering of pirated music, their music player on the web was the best. You have a list of songs, a search bar, and play/pause.
Nowadays Spotify web client takes a second or two to register mouse click. This is just sad.
They would have worked just fine on the web, and then some of those 150mb would be shared between all of them at least. I mean, we are talking glorified chat apps and music players, not 3d imagery or physics simulation. They even integrate pretty poorly (or not at all) with desktop systems, so really the whole Electron thing is just sad and often pointless.
One one had, the performance really sucks.
On the other, there's no way we would've had Spotify, Slack, Teams, and all these big apps supported on Linux.