Hacker News Reader

SOLUTION to high CPU!

Well, I kept digging and ultimately found a very long running issue thread[1] that mentioned having a .git directory in your home directory can cause high CPU.

Removing the three year old and accidentally created ~/.git directory and restarting Atom fixed the problem.

So now I will give Atom a deep new look.

Still, I am a bit perplexed, this is an issue that has been reported for nearly two years, and has not been fixed. I am not sure about the technical nature of the problem, but I think Atom, is trying to digest my entire 340GB home directory. Assuming that this is desired behavior, there should be at least a warning at launch about the issue. I am sure that MANY people have accidental ~/.git folders, and have a bad experience with Atom. At the vary least, it should not have taken me a couple hours of digging to find a solution buried in a GitHub issue.

While this fixes the issue on my MacBook, I am not sure about the Mac Mini, which I don't think will have a .git directory, but I will check later tonight.

[1] https://github.com/atom/atom/issues/3426#issuecomment-119780...

That's surprising and sort of disappointing to me. I _just_ (within the last week or 2) was setting up my $HOME to be .git controlled...and was thinking "Maybe I should give Atom another shot"

The GitHub issue the I created for Atom was closed almost right away with the comment that this problem has been fixed in the Atom 1.5 beta.

That's good to know, next time I'm evaluating whether to switch text editors (which happens plenty) - I'll have to keep that in mind (or more importantly try and not discount Atom immediately because 'Oh yeah, doesn't it have a problem with $HOME/.git?')

Of course Atom is not the lightest editor out there but your figures are really strange: I'm using atom for one year now with dozens of installed plugin, currently working with more than 10 files opened at the same time with an up-time of 17days and I've never seen anything like you.

except one notorious bug when trying to open minified javascript files of hundred kB.

That's weird to have such a difference performance-wise between users, because it's based on chromium which does not suffer plateform specific performance drops I think.

Do you have issues with Google Chrome also ?

I do not have any issues with Chrome.

To summarize my above findings.

For me the biggest problem here is the high CPU usage when the app should be idling. That KILLS battery life. I would not accept this behavior from high end video software, I certainly will not accept it from a text editor.

Following that the high RAM use can lead to swapping which will impact performance and battery live. As I said above after a clean install, and with just one short markdown file open, Atom is now using over 2GB RAM and Climbing. Fortunately, I have 16GB RAM on this system, otherwise I would already be swapping.

BBEdit and SublimeText never tax the CPU unless I am working with extremely large files, or doing search & replace on a huge number of files. I often will have 50 to 100 files open for days in these editors.

I like the evolving ecosystem of Atom, it now looks to be about on par with Sublime, and I can see that it will soon over take Sublime on that front. But it really need to get the resource utilization under control.

To be fair to Atom, I also tried installing it on a Mac Mini with an almost clean Mac OS X 10.11 installation. I had similar problems.

> BBEdit and SublimeText never tax the CPU unless I am working with extremely large files […] it really need to get the resource utilization under control

Neither does Atom for most users. It's not just n problem of «resource utilization», you're clearly facing a bug … Maybe you should consider submitting an issue (https://github.com/atom/atom/issues)

I see a number of current CPU related issues for Atom. I will look into using the performance diagnostic tools and see if I can contribute any new insights.

Again, I am see the issues on admittedly rather heavily customized workhorse MacBook (lots of Unix level tweets), AND on my stock Mac Mini. So I don't think this is a case isolated to just me.

As noted in this thread, I solved my problem, and filed an issue: https://github.com/atom/atom/issues/10421

Atom Helper sometimes gets a mind of its own and runs rampant on the CPU, sometimes eating 100% of a single core even an i7 2015 MacBook Pro. Quiting Atom doesn't seem to stop Atom helper. It takes firing up the Activity Monitor and quitting them. It's ugly but it works.

I've had this happen too. For me, disabling a continuously-fading cursor plugin stopped most of my troubles with high CPU. Still kind of ridiculous that to animate the color on a few dozen pixels constantly took so much CPU in 2015, but I'm guessing it was forcing redraws or something. Note that this was on an rMBP with integrated graphics if that matters.

I looked for the "continuously-fading cursor plugin" but found nothing. Is this built-in or an add-on?

Just tried VS Code, because I was curious... It seems to be using around 230MB of ram, and almost no CPU with a single file open... I was surprised how much better it worked compared to some of the other browser/nwjs/electron based editors. It's become my daily driver.

I am watching VS Code too. At the moment, Code's eco-system of add-on packages is missing too many tools I would want on a daily basis. However, I like the strong progress and road map, I could see Code being my go-to editor in the next year.

Actually, it has been a few months since I last checked on VS Code, I guess I should give it a spin again.

Just curious, what kinds of tools are essential for you to switch?

I use many of the features of Anaconda Python IDE. I know that better Python integration is high on the list priorities for VS Code, so I think this may happened.

http://damnwidget.github.io/anaconda/#

I tested out VS Code, seemed nice enough. Hopefully it'll get the tight integration with Git that Atom has. I have a love / hate relationship with Atom right now.

VS Code has much better git integration than Atom will ever have out of the box because Atom does not want to compete with GitHub for Desktop.

If true it's somewhat disheartening to see that newer companies are still carrying on the tradition of limiting a product (not that Atom is a "product" per se) in favor of promoting another one. I think there's a name coined for it but I can't recall it at the moment.

Weird. I don't get that on my system. Memory usage (according to top) is somewhere around 200 - 300 MB, cpu usage runs somewhere around 25% of a single core (on an i7).

The only time I get real lag on my system is when I'm opening a really, really large and minimized / mangled javascript file. Occasionally I get problems with the minimap or linters on very long files, but I have started regularly working with source files in the 5k - 10k lines range. I inherited and am refactoring and breaking down some monolithic stuff into more modular code, so there's a lot of tabbing around and copypasta in addition to regular coding, and atom's been responsive.

The thing I like about atom is that there's a pretty robust plugin ecosystem already.

This is the exact reason I don't use Atom.

It makes sense within the context of the Atom dream: to make a completely customizable editor, down to the pixel.

But Emacs has almost the exact same dream: to make a completely customizable editor, down to the character-grid cell.

This one small difference gives it way more performance, without much loss in my opinion.

Atom is extremely bloated in every sense of the term. It's bloated in CPU, in memory usage, in files, in libraries, in dependencies, in overall performance, in everything.

All because it wants to be customizable on the pixel level, rather than the character level.

I wish a new editor would arise to actually complete with Emacs. I hate this piece of junk editor, but it works, and it gets the job done.

I don't think pixel level customization is a major factor in bloat or performance. Doing it on top of a browser is what adds the majority of the overhead IMO.

(I haven't used Atom)

How come Atom is slow for so many people? Visual Studio Code is based on Electron as well and doesn't seem to have that. I tried VSCode for TypeScript and it was very smooth, not as good as Pycharm for my usecase though

Funny you mention that. I am thinking about switching. Vsc is much more performant built on electron which was what github developed to write atom.

So microsoft did a great job. Issue is that there is a much smaller community, less plugins and I have mac so no other ms synergy for me.

That said, I am going to try ot again today. I liked it

I have no idea what MS pulled to make Electron fast, because all other Electron-based apps that I've used have been absurdly slow.

VS Code isn't the fastest thing ever and uses more RAM than I'd like, but it definitely hits tolerable performance for me.

It's definitely the exception rather than the norm. I wish they'd publish something about writing efficient Electron apps.

Completely out of curiosity I checked the status of my emacs server:

    189 opened buffers (4 terminal sessions, rest are mixture of Ruby, Clojure, Javascript and Elisp files)
    < 1% CPU
    2 processes (server + attached editor)
    no idea about disk space probably around 100MB

Anecdotally, Atom runs fine on my MBP from 2012... Sure it's a bit of a hog resource wise, but I find that the benefits outweigh the cons.

> Sure it's a bit of a hog resource wise

I think that's his point. To some people, like leejoramo, if their text editor is a resource hog then it is not running fine.

It has zero effect on my workflow though. I can run Chrome, Safari (for testing), Outlook, Slack, music streaming, etc. without any slowdown when developing with Atom.

Edit: Just checked, after using Atom for two days straight it is currently occupying 80MB of ram. Anecdotally, the claim that Atom is a resource hog is actually wrong.

If you are running on battery power, the demands of Atom over something like BBEdit is a pretty big deal.

I'm on the same boat, as much as I'd love to love Atom, I keep installing it anew with every release only to get disappointed by the performance. Shame because it's an otherwise great editor.

I think the markdown-preview plugin may have issues because once I get to about a 400-500 line file it pegs my i5 at 100% CPU and takes 5-6 real life seconds to enter a single character.

This is on Linux. Other than that, I would say performance is reasonable on all projects I've worked with (couple hundred files in a folder while actively editing a handful at a time).

I didn't have a preview window open, but still tried disabling the core markdown-preview plugin. Unfortunately, no improvement.

Thank goodness. I was beginning to think it was just me.

I'm in the exact same boat. Other people tell me they like Atom and every single time I try to use it my system thinks I just set a vampire on the CPU.

See my solution elsewhere in this thread. You might have a ~/.git directory like I did.

Just checked and that doesn't seem to be it for me.

That seem pretty atypical... I'm trying everything I can think of, and I can't get the CPU above 40% utilization (and that was just a temporary spike while searching a massive directory of files).

For me, Atom idles at 0.5% CPU. 10 files open, 130MB of memory being consumed.

I'm fairly sensitive to slowness for an editor. Earlier versions of Atom had too much noticeable lag. Recently, though, it seems pretty performant.

Here is a way to reproduce an issue. Put syntax highlighing on discover.

Open a 1000 line json file. Most of the issues are on syntax highlighting. The editor has a very bad way of inplementing this, based on it always crashing or timing out.

Problem is fixed if sh is plaintext

The edit window closed, but to be fair I need to mention that the from 1.3 - 1.4(the new update), I opened the exact file I had significant problems with.

The editor used to bottle neck, hang, and usually would just quit after being non-responsive.

This has been fixed. The editor would take ~45-60 seconds (I timed it when i logged the issue on github). It now takes ~3 seconds. Sublimetext comparatively, is a bit better at <3 seconds, atom takes about 3-5 seconds and shakes out the highlighting over another 1 or 2. In total, you can start working on the file in about 4 seconds which is a big improvement over never/1 minute.

I'm curious how this compares to the browsers that use the same core technology that Atom uses.

3 projects open in separate windows with over 30 files being edited: http://imgur.com/uK7KbO8

There's something seriously wrong with your system's compatibility with Atom.

How about use dtrace to root cause the issue?

Look at file io, socket io patterns.

I downloaded Atom as a cool new thing to maybe use on my netbook.

It was more resource intensive than Visual Studio 2013 Community Edition lol.