Yeah, someone complains about the resource usage in every Atom post.
I feel likes it's a rehash of emacs vs vi debate from 30 years ago. Emacs needed many megabytes more than vi so people wouldn't use it.
As time goes on the resource usage becomes less of a problem. My 4 year old laptop has 16GB of RAM and I don't really worry about it. I'll get 32GB or 64GB in my next computer. I never liked quibbling over memory. My time is much more important to me and I want the best tools. I also want them to swim in RAM.
Yes, Emacs stands for "eight megabytes and constantly swapping". How silly this sounds today.
I wonder why do those people even care.
The only time I look at my resource usage is when apps start to behave funny. Or when it's an app that I am developing. Other than that, why should one care?
One argument could be made that they are using memory wastefully. Not sure that's the case. The baseline memory consumption is higher, so what? It's a tradeoff. It's easier to build a better editor using browser-based tools, as much as I like Elisp. Over time Atom and VSCode will close the gap.
Now, if there is a memory leak, or memory increases non-linearly with the workload, than it could be a problem. VI and Emacs are pretty great with large files (Emacs not so great with long lines), browser-based editors usually do not work as well. But there is no reason they shouldn't, it just takes engineering effort.
"Yes, Emacs stands for "eight megabytes and constantly swapping". How silly this sounds today. I wonder why do those people even care."
Well, because if an application you're using is constantly swapping, it'll slow that application down to a crawl. This was especially true back in the day when disk was slow (and expensive.. as was RAM).
People today are used to being awash in resources. RAM is fast, plentiful, and cheap. Disks are relatively fast and cheap.
You have to imagine what it was like to live in a resource-constrained environment where you actually had to care about how much memory and disk you used, and how you were using it. These decisions had severe, immediately apparent practical consequences.
What I meant to say was that "eight megabytes" sounds silly today. Who cares if an app uses 8MB today? The extrapolation is that it will be the same for Atom or other editors (I'd argue that it already is).
I created my first programs with a computer which had exactly 28815 bytes free when it booted up (out of a possible 64k). If you plugged in a floppy drive, the free memory dropped further.
Personally I don't mind RAM usage that much. I'm more concerned about excessive CPU usage resulting in unnecessary battery drain on my laptop or annoying fan-spinning.
Atom for me consistently sits at 0-0.1% (mostly 0) CPU usage when idling. You may want to investigate some of the extensions you're using if the numbers are different for you.
It was the lag (and at the time, struggling to open "large" files) that stopped me giving it more than a cursory check a year or so ago. No idea if it's worth looking into again? Would be hard to beat sublimes snappiness doing almost any task.
For certain definitions of 'high-end', maybe. You've been able to configure workstation-class laptops with 64 gb for a few years now.
And most mid- high-end laptops will happily accept 32GB, again going back a few years.
(Broadwell removed the density limitation that made 16GB DIMMs a no-go; anything that takes DDR4 should support 16GB SODIMMs, excepting the very low end Atom, Celeron etc.)
You really aren't. Atom runs fine on a Macbook Air. There are definitely performance issues, but we're addressing them; it's just that our team is small and our initial goal at launch was to produce the most hackable text editor possible.
I had to drop Atom when it began launching white flashes when scrolling on a 2011 MBA. I saw that this was a recurring problem. Is that an issue that is being addressed?
"I feel likes it's a rehash of emacs vs vi debate from 30 years ago. Emacs needed many megabytes more than vi so people wouldn't use it."
The thing is, this was in fact a valid critique of Emacs back in the day, and it cost Emacs users. I know I stopped using it back then partially because of its resource use (and because it was a lot slower than vi and because of its finger-twisting keyboard shortcuts).
If Emacs was as light on resources as vi was back then, it would have more users today.
I feel likes it's a rehash of emacs vs vi debate from 30 years ago. Emacs needed many megabytes more than vi so people wouldn't use it.
As time goes on the resource usage becomes less of a problem. My 4 year old laptop has 16GB of RAM and I don't really worry about it. I'll get 32GB or 64GB in my next computer. I never liked quibbling over memory. My time is much more important to me and I want the best tools. I also want them to swim in RAM.