Hacker News Reader

Hacker News

Comment by baldfat | Hacker News Reader

Full thread

baldfat

Atom is still a hog on my main programing machine. It makes it unusable for me still.

It is an OLD i3 Dell from 6 years ago desktop.

View on HN

Genuinely intrigued to keep seeing this persistent complaint with Atom.

I've been running it for ages on a mbp with 2.6GHz i5/8Gb RAM. It's lightning fast.

Very occasionally it will appear to be hogging CPU - typing is slow and it might hang for a couple of seconds when you're navigating around. This only seems to happen when I've had it running for days if not weeks without a restart. I just restart it and it's back to being lightning fast.

I really like Atom and would be pretty upset if it stopped working well for me, so would be curious to know what kinds of things people suspect cause it to have issues.

Is it just that my machine is powerful enough to not notice, and it's only really a problem on less powerful machines? I don't run many plugins, and installing many of these tend to bring it down? It runs well on OSX but not other platforms?

Packages can definitely have a significant impact on Atom's performance. You can observe all kinds of events, and binding a slow handler to certain events like text changes and cursor movements can make the editor feel sluggish.

It's important for Atom's extensibility that these kinds of events are provided, because it allows many major editor features to be implemented as separate packages, but it means that naively-implemented packages can really slow things down.

Many Atom packages are pretty new, and their authors may not have put a lot of effort into optimization yet. In the past few months, the team has put a lot of effort into stabilizing and solidifying our APIs. We're hoping that now that the APIs are stable, the package ecosystem will really start to mature.

What about a built-in mechanism to let you inspect what plugins are causing the most delay e.g. During a measuring period? Is that already a thing?

The best tool for that (and any profiling in Atom) is chromium's built-in profiler. See the flame graphs in the blog post.

I haven't had any speed issues with Atom either. It has worked well for me overall. What I don't get is the people who say Atom is slow and then say Intellij is fast. I'm not sure how I can take them seriously.

Editing text in Atom isn't instantaneous for me like MacVim or Sublime but the typing latency is low enough to not bother me (roughly 1-2 frames), roughly the same as the jetBrains family of IDEs. When I load up atom-typescript, typing latency takes a noticeable hit and drops to the annoyingly sluggish range (~3-4 frames). This is on a 2012 mba with a 1.8GHz i5. I also have 2-3s of startup delay and frequently have a half-second to second delay when opening a file. None of these are terrible but they're all noticeable.

I suspect that people who complain about speed are either on lower end hardware or are comparing it directly to a native editor directly and consider any typing latency at all to be unacceptable.

I am talking about 5 seconds a word speed. I type and it takes 5 seconds for my word to show up on the screen. I have default plugins nothing else installed.

> Very occasionally it will appear to be hogging CPU - typing is slow and it might hang for a couple of seconds when you're navigating around.

Do you literally mean that it hangs for a couple of seconds? That seems like an eternity, especially if it happens during navigation.

Literally, and in this state it is totally unusable. But let me emphasise this happens very rarely, once every couple of weeks maybe. When it does I just kick it over and it's fine.

Maybe try removing all plugins and retry. It's possible that one of them is responsible for this slowdown. This was the case for me couple of months ago.

Running `atom --safe` will start the editor with only bundled packages activated.

When was the last time you tried it? Atom works fine on dell computer with Intel duo core 2 from 7ish years ago.

I like Atom! However, sadly a simple regex search can kill it in 5 seconds.

This is exactly the case that is better as a result of these optimizations.

It's still much slower than, for example, Sublime Text. A search for a single letter [1] in a ~5,000 line file occurs instantly in ST, but takes about 1 second in Atom. It's not much, but it's very significant from a UI point of view.

[1] I know such a search is ridiculous, but both editors perform search-as-you-type, although atom does attempt to delay that if you type quickly enough. Anyway, it's just an example to demonstrate the speed difference.

There's still some major algorithmic optimization to be done regarding the time it takes to run the find-and-replace search. The optimizations discussed in this blog post were more focused on the performance of editing the buffer in the presence of large numbers of search results.

Right. Don't get me wrong, the article was interesting and I appreciate there's a lot of hard work going on. I really hope atom is a success because an open source equivalent of Sublime Text would be very welcome.

>"an open source equivalent of Sublime Text would be very welcome."

Good news, it exists. If you know Go it's possible to see it sooner: http://limetext.org/

Just like in emacs and vim there are plugins that let you use ack and grep: https://atom.io/packages/atom-fuzzy-grep

The built in search is slow (for now), but they have been steadily making gains and use performance testing to measure progress.

What OS are you running on the Dell?

OpenSUSE 13.2 with a tiled window manager and no other Desktops installed.

Reply on news.ycombinator.com