5 ms·

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.

by baldfat 11y ago

drudru11 11y ago
What OS are you running on the Dell?
- baldfat 11y ago
  OpenSUSE 13.2 with a tiled window manager and no other Desktops installed.
hugh4life 11y ago
When was the last time you tried it? Atom works fine on dell computer with Intel duo core 2 from 7ish years ago.
- vladikoff 11y ago
  I like Atom! However, sadly a simple regex search can kill it in 5 seconds.
  - mrbogle 11y ago
    This is exactly the case that is better as a result of these optimizations.
    - oneeyedpigeon 11y ago
      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.
      - maxbrunsfeld 11y ago
        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.
        oneeyedpigeon 11y ago
        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.
        ZenoArrow 11y ago
        >"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/ http://limetext.org/
      - crucialfelix 11y ago
        Just like in emacs and vim there are plugins that let you use ack and grep: https://atom.io/packages/atom-fuzzy-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.
davnicwil 11y ago
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?
- maxbrunsfeld 11y ago
  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.
  - seanp2k2 11y ago
    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?
    - maxbrunsfeld 11y ago
      The best tool for that (and any profiling in Atom) is chromium's built-in profiler. See the flame graphs in the blog post.
mirekrusin 11y ago
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.
- thedaniel 11y ago
  Running `atom --safe` will start the editor with only bundled packages activated.

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.

by baldfat 11y ago

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.

drudru11 11y ago

What OS are you running on the Dell?

baldfat 11y ago
OpenSUSE 13.2 with a tiled window manager and no other Desktops installed.

hugh4life 11y ago

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

vladikoff 11y ago
I like Atom! However, sadly a simple regex search can kill it in 5 seconds.
- mrbogle 11y ago
  This is exactly the case that is better as a result of these optimizations.
  - oneeyedpigeon 11y ago
    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.
    - maxbrunsfeld 11y ago
      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.
      - oneeyedpigeon 11y ago
        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.
        ZenoArrow 11y ago
        >"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/ http://limetext.org/
    - crucialfelix 11y ago
      Just like in emacs and vim there are plugins that let you use ack and grep: https://atom.io/packages/atom-fuzzy-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.

davnicwil 11y ago

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?

maxbrunsfeld 11y ago
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.
- seanp2k2 11y ago
  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?
  - maxbrunsfeld 11y ago
    The best tool for that (and any profiling in Atom) is chromium's built-in profiler. See the flame graphs in the blog post.

mirekrusin 11y ago

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.

thedaniel 11y ago
Running `atom --safe` will start the editor with only bundled packages activated.