6 ms·

Really gave atom a hard try. Back to notepad after a few months. The add-ons are the only advantage, but are grossly overshadowed by the resource consumption th

Really gave atom a hard try. Back to notepad after a few months. The add-ons are the only advantage, but are grossly overshadowed by the resource consumption this behemoth requires.

vlunkr 9y ago
I really hope you mean notepad++ or something
melling 9y ago
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.
- nulagrithom 9y ago
  > As time goes on the resource usage becomes less of a problem. Yet vim is still more popular today by a wide margin. :) It's not just about memory usage; it's about lag. Atom felt laggy to me. I also value my time, and I can't stand waiting for my editor.
  - have_faith 9y ago
    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.
    - outworlder 9y ago
      Sublime is still faster. But try VSCode. I do not notice any lag on the Mac. I still prefer Emacs due to the maturity of its packages. But I have used VSCode for a month and I have no complaints about the performance.
    - damieng 9y ago
      There's been a massive amount of performance work in the last year. Definitely give it another try :) (disclaimer, on the Atom team)
- dingo_bat 9y ago
  > My 4 year old laptop has 16GB of RAM Even now the highest end laptops have same 16GB RAM. Sad state of affairs :(
  - anoother 9y ago
    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.)
    - discreditable 9y ago
      Why am I expected to have a workstation-class laptop to run my text editor?
      - maxbrunsfeld 9y ago
        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.
        valesco 9y ago
        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?
        maxbrunsfeld 9y ago
        Do you remember if there was an issue opened for this on the Atom repo? I haven't heard of this problem.
- Shorel 9y ago
  > My time is much more important to me and I want the best tools. That's what I think, and the reason I use SublimeText.
  - esMazer 9y ago
    I don't mind resource usage, but I want speed! and SublimeText delivers on that front!
- andoma 9y ago
  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.
  - fro0116 9y ago
    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.
    - RussianCow 9y ago
      It's probably not idle CPU usage that the parent is complaining about.
    - andoma 9y ago
      Yeah, this was more a generic comment not specifically aimed at Atom. Sorry if that wasn't clear.
- outworlder 9y ago
  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.
  - pmoriarty 9y ago
    "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.
    - outworlder 9y ago
      Sorry, I wasn't clear enough. 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. So, I do understand resource constraints. Btw,
  - YaLTeR 9y ago
- pmoriarty 9y ago
  "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.
maxbrunsfeld 9y ago
Sorry to hear that. We’re improving Atom’s efficiency all the time, but there are definitely areas that we just haven’t gotten to yet.
- adtac 9y ago
  In your opinion, what, if improved, will give Atom the biggest performance boost?
  - maxbrunsfeld 9y ago
    I really want to create a public-facing roadmap that's specific to this issue. Unfortunately, our resources are limited so we often don't focus enough on blogging/publicizing our planning... but in the meantime, here's something of a brain dump: In terms of our actual data structures and algorithms, we're already starting to be in really good shape. We've dropped a number of components of our core TextBuffer to C++, ensured that most of our algorithms scale logarithmically with file size, cursor count, etc, and made use of native threading for important operations. 1. The one remaining structure that we need to drop to C++ is what we call the 'display index' - the thing that stores the locations of things like folds and soft wraps. Once we do that, opening large files (which is already reasonably fast) will be like butter. 2. Our find-and-replace is already pretty good - you can type without almost any lag even when we're storing the locations of millions of search results. But now that we have the ability to easily use background threads, there are some easy optimizations we could do there. The search results could really update instantaneously, we no longer need to wait until you pause when typing in the search box. 3. We have in the works a major change to our syntax highlighting system using my incremental parsing library Tree-sitter. Once this lands, it should eliminate any perceived latency in syntax highlighting (as well as enable a host of great syntax-related improvements). 4. Atom still uses synchronous IO (which blocks the UI thread) in some places. This is because it was created before GitHub created Electron, so node APIs were not available from the outset. Many of these have been eliminated, but there are several Git-related code paths that we still have not updated. This probably kills the experience of editing on remote drives like SSHFS for some users. We need to revisit these code paths.
Syntaf 9y ago
As did I, but I just couldn't get over how slow it was. Startup time on windows was rough, meaning I had to remove it as a default editor almost immediately for most filetypes. Worse off, opening large files would grind Atom to a halt and usually lock the editor up. Beyond the performance, I thought it was a great text editor. The problem is I just have no use for a slow-to-start editor when I can just DL vscode and get the same features with considerably better performance.

Really gave atom a hard try. Back to notepad after a few months. The add-ons are the only advantage, but are grossly overshadowed by the resource consumption this behemoth requires.

vlunkr 9y ago

I really hope you mean notepad++ or something

melling 9y ago

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.

nulagrithom 9y ago
> As time goes on the resource usage becomes less of a problem. Yet vim is still more popular today by a wide margin. :) It's not just about memory usage; it's about lag. Atom felt laggy to me. I also value my time, and I can't stand waiting for my editor.
- have_faith 9y ago
  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.
  - outworlder 9y ago
    Sublime is still faster. But try VSCode. I do not notice any lag on the Mac. I still prefer Emacs due to the maturity of its packages. But I have used VSCode for a month and I have no complaints about the performance.
  - damieng 9y ago
    There's been a massive amount of performance work in the last year. Definitely give it another try :) (disclaimer, on the Atom team)
dingo_bat 9y ago
> My 4 year old laptop has 16GB of RAM Even now the highest end laptops have same 16GB RAM. Sad state of affairs :(
- anoother 9y ago
  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.)
  - discreditable 9y ago
    Why am I expected to have a workstation-class laptop to run my text editor?
    - maxbrunsfeld 9y ago
      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.
      - valesco 9y ago
        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?
        maxbrunsfeld 9y ago
        Do you remember if there was an issue opened for this on the Atom repo? I haven't heard of this problem.
Shorel 9y ago
> My time is much more important to me and I want the best tools. That's what I think, and the reason I use SublimeText.
- esMazer 9y ago
  I don't mind resource usage, but I want speed! and SublimeText delivers on that front!
andoma 9y ago
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.
- fro0116 9y ago
  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.
  - RussianCow 9y ago
    It's probably not idle CPU usage that the parent is complaining about.
  - andoma 9y ago
    Yeah, this was more a generic comment not specifically aimed at Atom. Sorry if that wasn't clear.
outworlder 9y ago
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.
- pmoriarty 9y ago
  "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.
  - outworlder 9y ago
    Sorry, I wasn't clear enough. 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. So, I do understand resource constraints. Btw,
- YaLTeR 9y ago
pmoriarty 9y ago
"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.

maxbrunsfeld 9y ago

Sorry to hear that. We’re improving Atom’s efficiency all the time, but there are definitely areas that we just haven’t gotten to yet.

adtac 9y ago
In your opinion, what, if improved, will give Atom the biggest performance boost?
- maxbrunsfeld 9y ago
  I really want to create a public-facing roadmap that's specific to this issue. Unfortunately, our resources are limited so we often don't focus enough on blogging/publicizing our planning... but in the meantime, here's something of a brain dump: In terms of our actual data structures and algorithms, we're already starting to be in really good shape. We've dropped a number of components of our core TextBuffer to C++, ensured that most of our algorithms scale logarithmically with file size, cursor count, etc, and made use of native threading for important operations. 1. The one remaining structure that we need to drop to C++ is what we call the 'display index' - the thing that stores the locations of things like folds and soft wraps. Once we do that, opening large files (which is already reasonably fast) will be like butter. 2. Our find-and-replace is already pretty good - you can type without almost any lag even when we're storing the locations of millions of search results. But now that we have the ability to easily use background threads, there are some easy optimizations we could do there. The search results could really update instantaneously, we no longer need to wait until you pause when typing in the search box. 3. We have in the works a major change to our syntax highlighting system using my incremental parsing library Tree-sitter. Once this lands, it should eliminate any perceived latency in syntax highlighting (as well as enable a host of great syntax-related improvements). 4. Atom still uses synchronous IO (which blocks the UI thread) in some places. This is because it was created before GitHub created Electron, so node APIs were not available from the outset. Many of these have been eliminated, but there are several Git-related code paths that we still have not updated. This probably kills the experience of editing on remote drives like SSHFS for some users. We need to revisit these code paths.

Syntaf 9y ago

As did I, but I just couldn't get over how slow it was. Startup time on windows was rough, meaning I had to remove it as a default editor almost immediately for most filetypes. Worse off, opening large files would grind Atom to a halt and usually lock the editor up. Beyond the performance, I thought it was a great text editor. The problem is I just have no use for a slow-to-start editor when I can just DL vscode and get the same features with considerably better performance.