4 ms·

No, there is no irony there. HotSpot, under a typical configuration, eats up about 250MB just sitting there doing nothing. I don't know what Electron does unde

No, there is no irony there. HotSpot, under a typical configuration, eats up about 250MB just sitting there doing nothing. I don't know what Electron does under similar circumstances because I've never tried to measure it, but I know that I regularly see Electron apps using less than 70MB, so we can estimate an upper bound on Electron's typical contribution to bloat as being no more than ~30% of Java's. For a slightly more apples-to-apples comparison that's also quite a bit more apples-to-jicama, if I open vscode and IDEA on the same project (a small one I'm just getting started on), vscode and all its helpers are using 316MB, and IDEA is using 1.08GB. I doubt that much of that difference is actually attributable to using a browser rendering engine for GUI layout. In fact, I'm guessing that Chromium's net impact on the situation falls below the noise threshold of this comparison. So, yeah, not worried about it. FWIW, vscode also started up quite a bit faster, and I experience less keyboard lag when using it. And, if we're looking for mature and full-featred cross-platform GUI toolkits, that's about it for your options. Yes, there's QT, but, with a sticker price of $4000/developer/year, it's hard to criticize people for not choosing it. And there's GTK+, which is fine, I suppose, but not exactly everyone's cup of tea. Long story short: This Electron-flaming meme is getting old. If you don't like JavaScript, just come out and say it. If you don't like how Chromium is eating the world, that's a fair point, too. But stop scapegoating Electron for things like how Slack's desktop app used to leak memory at an astonishing rate. That was always the app developer's fault, not Electron's.

vlovich123 6y ago
QT is free if you’re OK linking it as LGPL.
vips7L 6y ago
> HotSpot, under a typical configuration, eats up about 250MB just sitting there doing nothing. This is much lower in newer jdk's [0]. > For a slightly more apples-to-apples comparison that's also quite a bit more apples-to-jicama, if I open vscode and IDEA on the same project (a small one I'm just getting started on), vscode and all its helpers are using 316MB, and IDEA is using 1.08GB I believe this to just be intellij bloat and not JVM because it just does too much. I run VSCode with the Java plugins and ZGC (read: eclipse language server, which is all jvm) and the language server only ends up using around 250mb of ram. [0] https://cl4es.github.io/2019/11/20/OpenJDK-Startup-Update.html https://cl4es.github.io/2019/11/20/OpenJDK-Startup-Update.ht...
- mumblemumble 6y ago
  I that you're right that it's just IntelliJ doing too much. Similar to how the Slack app's formerly astonishing memory consumption was because it was trying to retain all of Giphy in memory for all time. Somewhat related, back when I was a C# developer, I spent a long time being confused over the community's somewhat polar opinions on whether Visual Studio is slow and bloated, or lean and snappy. Eventually I realized that the difference of opinions was because some people's employers buy them copies of ReSharper, and others don't.
  - jolux 6y ago
    IntelliJ has more features than even the best language service I’ve used, C#’s. The language server tools are catching up but for integration and polish you still can’t beat JetBrains.
  - ptx 6y ago
    On the subject of the (lack of) snappiness in Visual Studio + ReSharper, Jetbrains Rider comes with the ReSharper functionality built in and feels a lot snappier.
    - nullsense 6y ago
      Rider is incredible. We lobbied for it at work a couple year ago and it's been so darn nice to use.
- deleted 6y ago
  [deleted]
ehvatum 6y ago
I dread the day Siemens inevitably buys Qt (it will happen) and the license structure changes to $65k/per-seat buy-in to the “base” toolkit which includes QObject and nothing else. Also, a $7k/year per-seat maintenance fee for “base”. If you want the QtGui module, look north of $100k buy-in.
- neutronicus 6y ago
  They certainly extract their pound of flesh for Parasolid Which to be fair is a very impressive piece of technology
NationalPark 6y ago
You'll have to post more about the OS and how you measured memory consumption. If you're just looking at something like htop, it can be pretty misleading.
ClumsyPilot 6y ago
I think this is a great comaprison of the wrong things - i do not believe RAM used is what matters, not if it's under 4 Gb. I think it's CPU, and VS code consistently takes more CPU to achoeve the same job, and for longer.
darksaints 6y ago
Slack's bloat may be the developer's fault, but the same could be said about Atom, and Discord, and Evernote, and Skype. And even if you can't say it about VSCode itself, you can certainly say it once you introduce a handful of extensions. Electron isn't the problem. All of the technologies it is built on are the problem. They require extreme measures to control quality and maintain performance for anything larger than a trivial crud app.
geodel 6y ago
Considering how avid Electron user tell others how files should not be even bigger than few hundred lines considering electron croaks on that. Or without irony they tell how fast Electron is on 6-core/32GB machines and that everyone should upgrade. They should be last person to talk anything about performance. > Long story short: This Electron-flaming meme is getting old. No I think it remains perfectly relevant today. And Electron products are not really enough shit that they so well deserve.
- bananaface 6y ago
  I feel like the sentiment that electron flaming is uncool because it's old (???) is indicative of a broader problem.
thu2111 6y ago
HotSpot, under a typical configuration, eats up about 250MB just sitting there doing nothing Mmmm, I have two projects open in IntelliJ right now, one of which is quite large, quite a few tabs, and it's using 366mb of heap. You have to watch out though - Java won't collect garbage if it doesn't have to. This fools a lot of people. They look at memory usage and assume it must really be using that much memory, even when it's not. From the perspective of the JVM if the memory is there, it may as well be used, because freeing RAM just to leave it pointlessly empty just wastes CPU time, battery, generates waste heap etc. Why not use it? The only time it matters is if you have something else that wants the memory and it can react to that I believe. Or if you're measuring it against other tools of course. I guess over time this will go away as a talking point because the JVM is getting more aggressive at collecting memory even when there's RAM spare, partly because of containers and partly because of threads like this one.
- gunnarmorling 6y ago
  That's already happening with modern JDKs and GCs; as of JDK 12, G1 uncommits unused heap eagerly (see https://openjdk.java.net/jeps/346 https://openjdk.java.net/jeps/346), and the parallel GCs Shenandoah and ZGC do the same.
exabrial 6y ago
> HotSpot, under a typical configuration, eats up about 250MB just sitting there doing nothing. Citation needed. Because right now we're running most our Apache TomEE and Tomcat applications in prod on a 64m or 128m heap and handle hundreds of requests or messages per second. And this is on an ancient JDK1.8. On JDK11, we're thinking of running between 16m and 32m heaps.
- dbt00 6y ago
  You do understand that heap size != memory footprint, right? The JVM has its own memory footprint before you start allocating java objects.
  - exabrial 6y ago
    Yes. So the absolute worst case scenario is one our 128mb heap apps that uses direct memory byte buffers for off-heap object caching. It's resident set size is roughly 387m, which up to 196m of that is byte buffers. I can tell using JPS the heap is full allocated, and the application has been running for several weeks so I imagine the cache is full. That leaves an overhead of 64m.
    - exabrial 6y ago
      For funzies, I looked at one our ActiveMQ Message brokers, which are ran on 1g machines with a 640m heap. The heaps are fully allocated and the resident set size is ~658m. Linux reports it has 66M of free memory and 95M of available ram. 440m of swap is being used and is only lightly being paged out under light load of 400 msgs/s. This same setup can push 2000msg/s before GC thrashing becomes an issue and we need more heap. So no, I don't think there's any truth to the claim "Hotspot always uses an extra 256m of memory". Sounds like the kernel is doing what it's supposed to: free memory is wasted memory.

vlovich123 6y ago

QT is free if you’re OK linking it as LGPL.

vips7L 6y ago

> HotSpot, under a typical configuration, eats up about 250MB just sitting there doing nothing. This is much lower in newer jdk's [0]. > For a slightly more apples-to-apples comparison that's also quite a bit more apples-to-jicama, if I open vscode and IDEA on the same project (a small one I'm just getting started on), vscode and all its helpers are using 316MB, and IDEA is using 1.08GB I believe this to just be intellij bloat and not JVM because it just does too much. I run VSCode with the Java plugins and ZGC (read: eclipse language server, which is all jvm) and the language server only ends up using around 250mb of ram. [0] https://cl4es.github.io/2019/11/20/OpenJDK-Startup-Update.html https://cl4es.github.io/2019/11/20/OpenJDK-Startup-Update.ht...

mumblemumble 6y ago
I that you're right that it's just IntelliJ doing too much. Similar to how the Slack app's formerly astonishing memory consumption was because it was trying to retain all of Giphy in memory for all time. Somewhat related, back when I was a C# developer, I spent a long time being confused over the community's somewhat polar opinions on whether Visual Studio is slow and bloated, or lean and snappy. Eventually I realized that the difference of opinions was because some people's employers buy them copies of ReSharper, and others don't.
- jolux 6y ago
  IntelliJ has more features than even the best language service I’ve used, C#’s. The language server tools are catching up but for integration and polish you still can’t beat JetBrains.
- ptx 6y ago
  On the subject of the (lack of) snappiness in Visual Studio + ReSharper, Jetbrains Rider comes with the ReSharper functionality built in and feels a lot snappier.
  - nullsense 6y ago
    Rider is incredible. We lobbied for it at work a couple year ago and it's been so darn nice to use.
deleted 6y ago
[deleted]

ehvatum 6y ago

I dread the day Siemens inevitably buys Qt (it will happen) and the license structure changes to $65k/per-seat buy-in to the “base” toolkit which includes QObject and nothing else. Also, a $7k/year per-seat maintenance fee for “base”. If you want the QtGui module, look north of $100k buy-in.

neutronicus 6y ago
They certainly extract their pound of flesh for Parasolid Which to be fair is a very impressive piece of technology

NationalPark 6y ago

You'll have to post more about the OS and how you measured memory consumption. If you're just looking at something like htop, it can be pretty misleading.

ClumsyPilot 6y ago

I think this is a great comaprison of the wrong things - i do not believe RAM used is what matters, not if it's under 4 Gb. I think it's CPU, and VS code consistently takes more CPU to achoeve the same job, and for longer.

darksaints 6y ago

Slack's bloat may be the developer's fault, but the same could be said about Atom, and Discord, and Evernote, and Skype. And even if you can't say it about VSCode itself, you can certainly say it once you introduce a handful of extensions. Electron isn't the problem. All of the technologies it is built on are the problem. They require extreme measures to control quality and maintain performance for anything larger than a trivial crud app.

geodel 6y ago

Considering how avid Electron user tell others how files should not be even bigger than few hundred lines considering electron croaks on that. Or without irony they tell how fast Electron is on 6-core/32GB machines and that everyone should upgrade. They should be last person to talk anything about performance. > Long story short: This Electron-flaming meme is getting old. No I think it remains perfectly relevant today. And Electron products are not really enough shit that they so well deserve.

bananaface 6y ago
I feel like the sentiment that electron flaming is uncool because it's old (???) is indicative of a broader problem.

thu2111 6y ago

HotSpot, under a typical configuration, eats up about 250MB just sitting there doing nothing Mmmm, I have two projects open in IntelliJ right now, one of which is quite large, quite a few tabs, and it's using 366mb of heap. You have to watch out though - Java won't collect garbage if it doesn't have to. This fools a lot of people. They look at memory usage and assume it must really be using that much memory, even when it's not. From the perspective of the JVM if the memory is there, it may as well be used, because freeing RAM just to leave it pointlessly empty just wastes CPU time, battery, generates waste heap etc. Why not use it? The only time it matters is if you have something else that wants the memory and it can react to that I believe. Or if you're measuring it against other tools of course. I guess over time this will go away as a talking point because the JVM is getting more aggressive at collecting memory even when there's RAM spare, partly because of containers and partly because of threads like this one.

gunnarmorling 6y ago
That's already happening with modern JDKs and GCs; as of JDK 12, G1 uncommits unused heap eagerly (see https://openjdk.java.net/jeps/346 https://openjdk.java.net/jeps/346), and the parallel GCs Shenandoah and ZGC do the same.

exabrial 6y ago

> HotSpot, under a typical configuration, eats up about 250MB just sitting there doing nothing. Citation needed. Because right now we're running most our Apache TomEE and Tomcat applications in prod on a 64m or 128m heap and handle hundreds of requests or messages per second. And this is on an ancient JDK1.8. On JDK11, we're thinking of running between 16m and 32m heaps.

dbt00 6y ago
You do understand that heap size != memory footprint, right? The JVM has its own memory footprint before you start allocating java objects.
- exabrial 6y ago
  Yes. So the absolute worst case scenario is one our 128mb heap apps that uses direct memory byte buffers for off-heap object caching. It's resident set size is roughly 387m, which up to 196m of that is byte buffers. I can tell using JPS the heap is full allocated, and the application has been running for several weeks so I imagine the cache is full. That leaves an overhead of 64m.
  - exabrial 6y ago
    For funzies, I looked at one our ActiveMQ Message brokers, which are ran on 1g machines with a 640m heap. The heaps are fully allocated and the resident set size is ~658m. Linux reports it has 66M of free memory and 95M of available ram. 440m of swap is being used and is only lightly being paged out under light load of 400 msgs/s. This same setup can push 2000msg/s before GC thrashing becomes an issue and we need more heap. So no, I don't think there's any truth to the claim "Hotspot always uses an extra 256m of memory". Sounds like the kernel is doing what it's supposed to: free memory is wasted memory.