3 ms·

> Consider any JavaScript desktop application, its power and memory usage... it's a mess. I'm running VSCode right now with many tabs open and extensions runni

> Consider any JavaScript desktop application, its power and memory usage... it's a mess. I'm running VSCode right now with many tabs open and extensions running, and it's using less than 100mb of memory. Doesn't seem so bad to me

diego_moita 7y ago
> using less than 100mb of memory. Doesn't seem so bad to me You know... any embedded programmer reading that comment is probably laughing hysterically. In most cheap or energy efficient microcontrolers, more than 4 Mb is considered a luxury.
- lispm 7y ago
  A friend of mine has been developing a small Lisp which starts at 2Kbytes RAM: http://www.ulisp.com http://www.ulisp.com
- airza 7y ago
  I mean sure, but he's talking about desktop applications.
- Const-me 7y ago
  Depends on the exact numbers. For instance, Allwinner R328 chip has 2 ARM cores running up to 1.2GHz, includes 64MB or 128MB RAM, and the price is around $3.
- UncleMeat 7y ago
  Ok. There is no virtue in using less memory for the sake of it. If a desktop application is taking 100mb, you can have a lot of those running before modern boxes start to struggle.
  - deleted 7y ago
    [deleted]
- mntmoss 7y ago
  Whether 100Mb usage is unacceptably large is mostly dependent on the precise features in play: * 32-bit vs 64-bit application(64 bit will bloat all pointers) * Methods of loading and editing documents(modern editing attempts a lot of introspection based on highlighting syntax or project environment) * Character encoding support(Supporting current Unicode rendering would almost immediately take you beyond 4Mb) Interactive editing is a pretty memory-hungry task compared to a simple viewer or batch processor. There's more reason to keep things cached. If you actually go back to old text editor versions from the days of 4Mb desktops, you'll find yourself missing stuff. Not so much that you can't get by, but enough to give pause and consider taking the hit.
LandR 7y ago
100 mb to edit text seems not great...
- archie2 7y ago
  VS Code does a lot more than "edit text" even out of the box with no extensions.
- evilduck 7y ago
  Have you ever installed enough Vim or Emacs plugins to reach feature parity and then looked at memory usage? VS Code is doing a fine job.
doublement 7y ago
~100,000,000 bytes! That's a lot of "state".
rvanmil 7y ago
Are you sure you didn’t forget to count all the electron helper processes as well?
jcelerier 7y ago
> I'm running VSCode right now with many tabs open and extensions running, and it's using less than 100mb of memory. Doesn't seem so bad to me uh... is it ? no tabs open and less than 12 extensions, the code process itself takes 120 megabytes, and there's also 1.2 gigabyte of electron processes running along with it

diego_moita 7y ago

> using less than 100mb of memory. Doesn't seem so bad to me You know... any embedded programmer reading that comment is probably laughing hysterically. In most cheap or energy efficient microcontrolers, more than 4 Mb is considered a luxury.

lispm 7y ago
A friend of mine has been developing a small Lisp which starts at 2Kbytes RAM: http://www.ulisp.com http://www.ulisp.com
airza 7y ago
I mean sure, but he's talking about desktop applications.
Const-me 7y ago
Depends on the exact numbers. For instance, Allwinner R328 chip has 2 ARM cores running up to 1.2GHz, includes 64MB or 128MB RAM, and the price is around $3.
UncleMeat 7y ago
Ok. There is no virtue in using less memory for the sake of it. If a desktop application is taking 100mb, you can have a lot of those running before modern boxes start to struggle.
- deleted 7y ago
  [deleted]
mntmoss 7y ago
Whether 100Mb usage is unacceptably large is mostly dependent on the precise features in play: * 32-bit vs 64-bit application(64 bit will bloat all pointers) * Methods of loading and editing documents(modern editing attempts a lot of introspection based on highlighting syntax or project environment) * Character encoding support(Supporting current Unicode rendering would almost immediately take you beyond 4Mb) Interactive editing is a pretty memory-hungry task compared to a simple viewer or batch processor. There's more reason to keep things cached. If you actually go back to old text editor versions from the days of 4Mb desktops, you'll find yourself missing stuff. Not so much that you can't get by, but enough to give pause and consider taking the hit.

LandR 7y ago

100 mb to edit text seems not great...

archie2 7y ago
VS Code does a lot more than "edit text" even out of the box with no extensions.
evilduck 7y ago
Have you ever installed enough Vim or Emacs plugins to reach feature parity and then looked at memory usage? VS Code is doing a fine job.

doublement 7y ago

~100,000,000 bytes! That's a lot of "state".

rvanmil 7y ago

Are you sure you didn’t forget to count all the electron helper processes as well?

jcelerier 7y ago

> I'm running VSCode right now with many tabs open and extensions running, and it's using less than 100mb of memory. Doesn't seem so bad to me uh... is it ? no tabs open and less than 12 extensions, the code process itself takes 120 megabytes, and there's also 1.2 gigabyte of electron processes running along with it