3 ms·

Don't want to create a flame war, but let's look at real world stats, at least for me, the overhead is very minimal. Look at the screenshot of my macbook pro 20

Don't want to create a flame war, but let's look at real world stats, at least for me, the overhead is very minimal. Look at the screenshot of my macbook pro 2013. I am running vscode for 100% of my development time. In the graph, I have sorted the processes by CPU Time (Not just CPU). That is the average amount of CPU used by each process over time. I have also included memory usage. While the total memory comes to around 400mb, it's still lesser than some Java based IDEs. For an app that I use as my main IDE, the resource usage (CPU) is very minimal. cpu usage https://www.dropbox.com/s/x743mmnqvnffja1/cpu.png?dl=0 https://www.dropbox.com/s/x743mmnqvnffja1/cpu.png?dl=0 memory usage https://www.dropbox.com/s/twss8stdl12j83n/memory.png?dl=0 https://www.dropbox.com/s/twss8stdl12j83n/memory.png?dl=0

stephenr 9y ago
> it's still lesser than some Java based IDEs Once you have Java based IDE's like the IntellJ/IDEA family etc in the mix, you can't really call editors like VSCode/Atom/etc an IDE. The functionality is nowhere near the same. I don't like relying on a Java tool. IDEA Ultimate uses a lot of memory. But it has a lot of functionality too, which is why I accept the JVM overhead. If someone produced a fully featured IDE (or even plugins e.g. for Xcode) for macOS that was a true native app, I'd use that. But that doesn't exist. The options for me are: true native editors (Coda, TextMate, CotEdit, etc), web-page-as-an-app, slightly more featured editors (VS Code, Atom), fully featured IDEs (IntelliJ IDEA, maybe ActiveState KomodoIDE, possibly a NetBeans/etc setup).
- murukesh_s 9y ago
  > But it has a lot of functionality too, which is why I accept the JVM overhead This is something that can be replicated with additional plugins. To be honest, I have used Eclipse and Netbeans extensively. They do have additional features, but not a lot. If I am not wrong, VSCode ships with a debugger and syntax highlighter built-in. There are tons of other plugins to add the extra functionality like GIT integration, built-in terminal, more syntax highlighting etc (Nowadays, you name it you have it). Even if you add 10 such plugins you are noway near a JVM based IDE on memory consumption. Also Netbeaans is very very slow, atleast in perception. Eclipse feels snappy, due to the use of SWT, but its a memory hog.
  - stephenr 9y ago
    I'm talking about stuff like: - Static analysis of code - Find calls to methods - Find usage of Classes/Interfaces/Variables - Alert when classes don't properly implement interfaces/abstract methods - Detect language-level syntax/feature changes/compatibility - Code refactoring - Rename variables/classes/interfaces - Change method signatures - Pull/push methods to parent/child classes
    - murukesh_s 9y ago
      Most of the above features dont need constant monitoring, so adding a plugin for that purpose won't add any large overhead. And many plugins do similar tasks in Atom/VSCode with minimal overhead. Even for continuous monitoring of filesystem, node.js is very fast(there are many native plugins). Disclaimer: I am developing an IDE using electron for a visual programming language. I have worked on JRE based IDE toolkits before (SWT/Swing). Both the runtime performance and developer experience appear better to me. You can of course get better performance if you directly write in the platforms native stack, but my point is that JRE is only as good as a properly architected Electron stack.
      - stephenr 9y ago
        > Most of the above features don't need constant monitoring The above features flat out aren't available in the Electron based editors people like to call IDE's now. Im not talking about how possible it is to implement them - I'm explaining why I accept the overhead of a JVM based IDE, but won't accept an Electron one: the JVM one (JetBrains IDEA) has those features, none of the other options on macOS have them.
simion314 9y ago
VS Code has less features then the main Visual Studio and Intellij IDEs, also I don't think the problem is the language but Electron. About memory uisage, garbage collected languages will show a larger memory usage because they will not start cleanup when an object is freed, it waits until it needs free memory and then it starts the GC and in Java I think you can specify options to control this,CPU usage is more important since that uses battery/enrgy
- murukesh_s 9y ago
  JVM has the same problem, isn't it?. In fact VSCode even after extending it with lots of plugin to make it a full-fledged IDE, feels more responsive and relatively lean on memory usage compared to full-fledged (JVM based) IDEs.
  - simion314 9y ago
    If you think VS Code with all plugins is an IDE at the level of Intellij or the main Vs then why VS still exists? Maybe you did not used this large IDEs so you don't know what the features or speed is, maybe your projects work good enough with VS Code or a plain text editor(not all projects need a big IDE). My opinion is that Electron needs more optimizations, and the developers that use it need better tools and need to also care more about the CPU usage. Even if you would use c and compile to web assembly to run n electron the problems would still be there so not the Language is at fault but the implementation.

stephenr 9y ago

> it's still lesser than some Java based IDEs Once you have Java based IDE's like the IntellJ/IDEA family etc in the mix, you can't really call editors like VSCode/Atom/etc an IDE. The functionality is nowhere near the same. I don't like relying on a Java tool. IDEA Ultimate uses a lot of memory. But it has a lot of functionality too, which is why I accept the JVM overhead. If someone produced a fully featured IDE (or even plugins e.g. for Xcode) for macOS that was a true native app, I'd use that. But that doesn't exist. The options for me are: true native editors (Coda, TextMate, CotEdit, etc), web-page-as-an-app, slightly more featured editors (VS Code, Atom), fully featured IDEs (IntelliJ IDEA, maybe ActiveState KomodoIDE, possibly a NetBeans/etc setup).

murukesh_s 9y ago
> But it has a lot of functionality too, which is why I accept the JVM overhead This is something that can be replicated with additional plugins. To be honest, I have used Eclipse and Netbeans extensively. They do have additional features, but not a lot. If I am not wrong, VSCode ships with a debugger and syntax highlighter built-in. There are tons of other plugins to add the extra functionality like GIT integration, built-in terminal, more syntax highlighting etc (Nowadays, you name it you have it). Even if you add 10 such plugins you are noway near a JVM based IDE on memory consumption. Also Netbeaans is very very slow, atleast in perception. Eclipse feels snappy, due to the use of SWT, but its a memory hog.
- stephenr 9y ago
  I'm talking about stuff like: - Static analysis of code - Find calls to methods - Find usage of Classes/Interfaces/Variables - Alert when classes don't properly implement interfaces/abstract methods - Detect language-level syntax/feature changes/compatibility - Code refactoring - Rename variables/classes/interfaces - Change method signatures - Pull/push methods to parent/child classes
  - murukesh_s 9y ago
    Most of the above features dont need constant monitoring, so adding a plugin for that purpose won't add any large overhead. And many plugins do similar tasks in Atom/VSCode with minimal overhead. Even for continuous monitoring of filesystem, node.js is very fast(there are many native plugins). Disclaimer: I am developing an IDE using electron for a visual programming language. I have worked on JRE based IDE toolkits before (SWT/Swing). Both the runtime performance and developer experience appear better to me. You can of course get better performance if you directly write in the platforms native stack, but my point is that JRE is only as good as a properly architected Electron stack.
    - stephenr 9y ago
      > Most of the above features don't need constant monitoring The above features flat out aren't available in the Electron based editors people like to call IDE's now. Im not talking about how possible it is to implement them - I'm explaining why I accept the overhead of a JVM based IDE, but won't accept an Electron one: the JVM one (JetBrains IDEA) has those features, none of the other options on macOS have them.

simion314 9y ago

VS Code has less features then the main Visual Studio and Intellij IDEs, also I don't think the problem is the language but Electron. About memory uisage, garbage collected languages will show a larger memory usage because they will not start cleanup when an object is freed, it waits until it needs free memory and then it starts the GC and in Java I think you can specify options to control this,CPU usage is more important since that uses battery/enrgy

murukesh_s 9y ago
JVM has the same problem, isn't it?. In fact VSCode even after extending it with lots of plugin to make it a full-fledged IDE, feels more responsive and relatively lean on memory usage compared to full-fledged (JVM based) IDEs.
- simion314 9y ago
  If you think VS Code with all plugins is an IDE at the level of Intellij or the main Vs then why VS still exists? Maybe you did not used this large IDEs so you don't know what the features or speed is, maybe your projects work good enough with VS Code or a plain text editor(not all projects need a big IDE). My opinion is that Electron needs more optimizations, and the developers that use it need better tools and need to also care more about the CPU usage. Even if you would use c and compile to web assembly to run n electron the problems would still be there so not the Language is at fault but the implementation.