9 ms·

The new features and updates are great, but the one thing holding me back from using it is the fact it is extremely slow and laden with performance issues. Anyo

The new features and updates are great, but the one thing holding me back from using it is the fact it is extremely slow and laden with performance issues. Anyone who has ever attempted to open a file with a lot of lines of code will attest to the fact that Atom has issues. Ironically, Microsoft's open source Visual Studio Code editor is based in part of some aspects of Atom and it has exceptional performance and is a great editor in comparison. They need to focus on fixing the slowness. VSCode proved that Electron is not the bottleneck but rather Atom's code itself is.

BinaryIdiot 11y ago
Define "a lot of lines". I have used Atom almost every day for the last couple of years now. Startup and opening files of, say, 5mb or larger sucks. But I've never had an issue with opening typical file sizes. I switched to Atom mostly because of the plugins but I still keep sublime installed for the rare occasions I need to open a large file. Now I'll admin there have been a few times when I haven't closed Atom for weeks and it'll act a little slow while typing (which can be really frustrating) but closing it and reopening it always fixes it (I'm assuming some memory leak is the culprit).
- santaclaus 11y ago
  I just tried opening a 6.3 meg xml file, and Atom was almost unusably slow. Sublime Text opened the file almost immediately and was responsive off the bat.
  - lobster_johnson 11y ago
    Tested with a real XML file here: # wc -l t.xml 315479 t.xml # wc -c t.xml 10377128 t.xml Unlike Sublime, it doesn't syntax highlight for some reason, but it does open. Opens quite fast, too. Editing, cursor movement, pagination, etc. all super fast. OS X 10.11.3, Atom 1.6.0 on a MacBook Pro (Retina mid-2015, 2.8GHz Core i7, 16GB RAM, AMD Radeon R9 M370X).
    - santaclaus 11y ago
      Interesting -- disabling the xml plugin significantly improves performance for me (but I lose syntax highlighting).
      - lobster_johnson 11y ago
        Do you mean the built-in "language-xml" package or something else? FWIW, I have it enabled.
        santaclaus 11y ago
        > Do you mean the built-in "language-xml" package or something else? FWIW, I have it enabled. Yes, I'm using the built-in language-xml version 0.34.2.
      - jug 11y ago
        I sure hope it doesn't try to highlight the entire thing, and instead just what is visible on-screen.
        josephlord 11y ago
        With most languages and things like XML it will need to have parsed from the start to the visible area to understand the context (e.g. what if there is comment that started 1000 lines earlier but hasn't yet been closed).
    - santaclaus 11y ago
      > Unlike Sublime, it doesn't syntax highlight for some reason, but it does open. Perhaps Atom is disabling syntax highlighting for sufficiently large files? Edit: Interesting experiment. Open a small xml file, and syntax highlighting is active. Open a large xml file, and Atom doesn't syntax highlight. Copy and paste the contents of the large xml file without highlighting into the small file with highlighting, and after the text is copied there is a massive slowdown as Atom syntax highlights. I was able to scroll down the file and watch the syntax highlighting slowly propagate through the file.
voltagex_ 11y ago
I've been trying to work out what makes VSC so much faster than Atom. Whatever magic Microsoft did really needs to make it back upstream because it'll make using Electron-based apps much less frustrating.
- altano 11y ago
  This is a common misconception. Electron is a really tiny slice of these two text editors. Atom and VS Code are text editors and they have completely different code bases for the text editing, so there isn't anything that can be moved upstream. Monaco, the text editor at the heart of VS Code, is just a lot better (and older and more mature) than Atom's. Perhaps Atom will eventually catch up or simply switch over to Monaco.
- PeCaN 11y ago
  Yeah. I thought building a text editor in a web shell was incredibly stupid until I tried VSC. It's still more memory hungry than I'd like, but it's really fast—as fast as Vim for me (but noticeably slower than NeoVim). Did MS actually modify Electron, did they just write better JS, or some of both?
  - voltagex_ 11y ago
    The reply above yours seems to think it's "just" Electron with better JS, but I'm pretty sure Atom doesn't have DirectX acceleration ;)
    - Guillaume86 11y ago
      It's open source, check by yourself: https://github.com/Microsoft/vscode/blob/master/build/gulpfile.vscode.js https://github.com/Microsoft/vscode/blob/master/build/gulpfi... which use https://github.com/joaomoreno/gulp-atom-electron https://github.com/joaomoreno/gulp-atom-electron to fetch electron
hacker_9 11y ago
Seeing as quite a few people here are complaining about the performance of Atom, I thought I'd give it a try see if there's anything to it. Cloned the 'Phaser' javascript game engine repo off GitHub and went through a few files (each with 500-1000 LOC), did some editing and... didn't have a single problem with performance. I can only imagine that you and the other complainers are running older computers that can't keep up, or you've got a load of other programs running and your PC is having to use virtual memory. I thought it strange that Atom wouldn't focus on performance if it were such a problem as is being made out, but it seems that this is just the case for the vocal minority once again.
- mrcwinn 11y ago
  Nope, completely wrong. I have a 32GB i7-4790K at around 4Ghz or so, and Atom is a complete dog. The painful truth is that a webview is never going to beat a native app at this kind of task. It's not a vocal minority. Atom is painful to use compared to, say, Sublime.
  - 13years 11y ago
    I suspect that both are right. Some people are having issues and others are not. I don't seem to have any lag at all when typing even with multi megabyte size files. Maybe you could give some more details into exactly what actions were slow for you and what types of files you were editing. Actually, thanks to innovations in Mozilla's servo, the web may actually become faster than native.
  - hacker_9 11y ago
    You expect me to believe that with those specs Atom really runs like a 'complete dog'? The fact you also mention Sublime too really just tells me that your opinion was biased from the start. Finally, JIT compiled languages can be just as fast as native, simply because they can optimise to your hardware specs. You are getting mixed up as to why things are the way they are; JavaScript is a dynamically typed language, so the engine doesn't know AOT what types have what members, so this can cause a slow down compared to statically typed languages. BUT any JavaScript engine worth it's salt quickly figures the stuff out on startup so it's not a problem, as long as you don't use too many dynamic tricks that it can't optimise.
timr 11y ago
I simply don't understand the appeal of the thing. To a person, everyone who raves about it says, essentially "just like Sublime Text, but in Javascript!", and yeah, that seems right. Just like Sublime Text, but in Javascript...and plagued with the performance problems you'd expect from Sublime Text, written in JavaScript. There's not really a killer feature that makes me want to switch from the editor I use already. I must be getting old, because "...but in JavaScript!" is not a selling point to me. I don't care what language my editor is written in, except that I'd prefer it to be written in whatever language allows the developers to implement its features in a performant and scalable fashion. (I really love the downvotes for disagreement. Perhaps, if you like the thing so much, you could explain why, instead of just trying to silence people?)
- csallen 11y ago
  I suspect the primary reason people like the fact that it's written in JavaScript is because a lot of people know JavaScript. That makes Atom eminently hackable.
  - timr 11y ago
    Yeah, OK...but Sublime Text is eminently hackable in Python, and it doesn't get the same sort of rabid adoption from Python devs (it's popular, sure, but not more so than vi or emacs).
- AlexMax 11y ago
  > Perhaps, if you like the thing so much, you could explain why I am an avid Atom user who acknowledges how slow the thing can be. None of the slowness on my end approaches any of the horror stores in these threads, but for me, opening the program from a cold boot takes long enough for the wait to irritate me, the first time I save any file after opening the program takes a second or two, and opening a new window takes a second or two. However, I stick with Atom for a few reasons. First, Atom is like Sublime Text, but nicer. It has real settings pages! It has a built-in package manager! And although you might consider the fact that it's written in what is essentially a web browser to be a downside, there is a huge upside in that packages can create interfaces with that flexibility that Sublime Text simply can't match - compare something like this https://atom.io/packages/php-debug https://atom.io/packages/php-debug with Sublime Text's best-effort https://github.com/martomo/SublimeTextXdebug https://github.com/martomo/SublimeTextXdebug . Not only is trying to assemble an interface out of text buffers not as flexible as a webpage, they also tend to be brittle and break in odd ways if you do any window manipulation on your own - this is actually a complaint I have about Emacs and Vim as well. Also, it just feels like Atom's plugin API is more complete in general - I remember there being a Sublime Text package that required making a copy of your theme so it could add its own styles, and I haven't seen anything similarly hacky in Atom yet. Second, Atom is open source. I had bought both Textmate and Sublime Text and both of those editors had updates slow to an absolute crawl to the point where it felt like the developer had abandoned them. I feel like Atom being open source makes it less likely to be abandoned completely, especially considering how vibrant the community that has sprung up around the editor.
girvo 11y ago
> extremely slow and laden with performance issues I've honestly not experienced this at all; though I'm running Atom/Nuclide with only the Babel language plugin extra.
- csallen 11y ago
  I think you hit the nail on the head. Slowness in Atom varies so much from person to person probably because it's not in the editor itself, but in the plugins, and everyone has different plugins installed.
  - girvo 11y ago
    Right, that's probably the case. And funnily, the reason why I'm so picky about plugins is that I managed to make both Vim and Sublime Text run horrendously via plugin overload.
    - azinman2 11y ago
      Sounds like both should do a better job of telling you which plugins are slowing your system
      - timlyo 11y ago
        Atom has something to help with that: https://github.com/atom/timecop https://github.com/atom/timecop
- aeturnum 11y ago
  I've tried running atom several times over its history - first for go and again for elixir. Both times I've had the base version of atom with one or two plugins (go-plus / language-elixir & autocomplete-elixir). I found that, even with that setup, Atom was noticeably slower for all aspects of text editing (opening, navigating, typing, selecting, etc). I also found that the plugins did not work as well as the sublime text equivalents I'd been using (though that's not really Atom's fault). I really like the idea of atom, but I've found the practical product less than compelling.
tombert 11y ago
I agree with the first point there. I was pretty excited to try an "open source version of sublime text", but the performance was so terrible I ended up just sticking with Vim. I know people are trying to back away from the console-ui editors, but you cannot deny that,performance wise, it's tough to beat Vim or Emacs.
discreditable 11y ago
Agreed. Atom's performance is it's biggest problem. I've been trying it lately and the startup times are very annoying. I find myself reaching for Notepad++ most often just because I don't feel like waiting.

BinaryIdiot 11y ago

Define "a lot of lines". I have used Atom almost every day for the last couple of years now. Startup and opening files of, say, 5mb or larger sucks. But I've never had an issue with opening typical file sizes. I switched to Atom mostly because of the plugins but I still keep sublime installed for the rare occasions I need to open a large file. Now I'll admin there have been a few times when I haven't closed Atom for weeks and it'll act a little slow while typing (which can be really frustrating) but closing it and reopening it always fixes it (I'm assuming some memory leak is the culprit).

santaclaus 11y ago
I just tried opening a 6.3 meg xml file, and Atom was almost unusably slow. Sublime Text opened the file almost immediately and was responsive off the bat.
- lobster_johnson 11y ago
  Tested with a real XML file here: # wc -l t.xml 315479 t.xml # wc -c t.xml 10377128 t.xml Unlike Sublime, it doesn't syntax highlight for some reason, but it does open. Opens quite fast, too. Editing, cursor movement, pagination, etc. all super fast. OS X 10.11.3, Atom 1.6.0 on a MacBook Pro (Retina mid-2015, 2.8GHz Core i7, 16GB RAM, AMD Radeon R9 M370X).
  - santaclaus 11y ago
    Interesting -- disabling the xml plugin significantly improves performance for me (but I lose syntax highlighting).
    - lobster_johnson 11y ago
      Do you mean the built-in "language-xml" package or something else? FWIW, I have it enabled.
      - santaclaus 11y ago
        > Do you mean the built-in "language-xml" package or something else? FWIW, I have it enabled. Yes, I'm using the built-in language-xml version 0.34.2.
    - jug 11y ago
      I sure hope it doesn't try to highlight the entire thing, and instead just what is visible on-screen.
      - josephlord 11y ago
        With most languages and things like XML it will need to have parsed from the start to the visible area to understand the context (e.g. what if there is comment that started 1000 lines earlier but hasn't yet been closed).
  - santaclaus 11y ago
    > Unlike Sublime, it doesn't syntax highlight for some reason, but it does open. Perhaps Atom is disabling syntax highlighting for sufficiently large files? Edit: Interesting experiment. Open a small xml file, and syntax highlighting is active. Open a large xml file, and Atom doesn't syntax highlight. Copy and paste the contents of the large xml file without highlighting into the small file with highlighting, and after the text is copied there is a massive slowdown as Atom syntax highlights. I was able to scroll down the file and watch the syntax highlighting slowly propagate through the file.

voltagex_ 11y ago

I've been trying to work out what makes VSC so much faster than Atom. Whatever magic Microsoft did really needs to make it back upstream because it'll make using Electron-based apps much less frustrating.

altano 11y ago
This is a common misconception. Electron is a really tiny slice of these two text editors. Atom and VS Code are text editors and they have completely different code bases for the text editing, so there isn't anything that can be moved upstream. Monaco, the text editor at the heart of VS Code, is just a lot better (and older and more mature) than Atom's. Perhaps Atom will eventually catch up or simply switch over to Monaco.
PeCaN 11y ago
Yeah. I thought building a text editor in a web shell was incredibly stupid until I tried VSC. It's still more memory hungry than I'd like, but it's really fast—as fast as Vim for me (but noticeably slower than NeoVim). Did MS actually modify Electron, did they just write better JS, or some of both?
- voltagex_ 11y ago
  The reply above yours seems to think it's "just" Electron with better JS, but I'm pretty sure Atom doesn't have DirectX acceleration ;)
  - Guillaume86 11y ago
    It's open source, check by yourself: https://github.com/Microsoft/vscode/blob/master/build/gulpfile.vscode.js https://github.com/Microsoft/vscode/blob/master/build/gulpfi... which use https://github.com/joaomoreno/gulp-atom-electron https://github.com/joaomoreno/gulp-atom-electron to fetch electron

hacker_9 11y ago

Seeing as quite a few people here are complaining about the performance of Atom, I thought I'd give it a try see if there's anything to it. Cloned the 'Phaser' javascript game engine repo off GitHub and went through a few files (each with 500-1000 LOC), did some editing and... didn't have a single problem with performance. I can only imagine that you and the other complainers are running older computers that can't keep up, or you've got a load of other programs running and your PC is having to use virtual memory. I thought it strange that Atom wouldn't focus on performance if it were such a problem as is being made out, but it seems that this is just the case for the vocal minority once again.

mrcwinn 11y ago
Nope, completely wrong. I have a 32GB i7-4790K at around 4Ghz or so, and Atom is a complete dog. The painful truth is that a webview is never going to beat a native app at this kind of task. It's not a vocal minority. Atom is painful to use compared to, say, Sublime.
- 13years 11y ago
  I suspect that both are right. Some people are having issues and others are not. I don't seem to have any lag at all when typing even with multi megabyte size files. Maybe you could give some more details into exactly what actions were slow for you and what types of files you were editing. Actually, thanks to innovations in Mozilla's servo, the web may actually become faster than native.
- hacker_9 11y ago
  You expect me to believe that with those specs Atom really runs like a 'complete dog'? The fact you also mention Sublime too really just tells me that your opinion was biased from the start. Finally, JIT compiled languages can be just as fast as native, simply because they can optimise to your hardware specs. You are getting mixed up as to why things are the way they are; JavaScript is a dynamically typed language, so the engine doesn't know AOT what types have what members, so this can cause a slow down compared to statically typed languages. BUT any JavaScript engine worth it's salt quickly figures the stuff out on startup so it's not a problem, as long as you don't use too many dynamic tricks that it can't optimise.

timr 11y ago

I simply don't understand the appeal of the thing. To a person, everyone who raves about it says, essentially "just like Sublime Text, but in Javascript!", and yeah, that seems right. Just like Sublime Text, but in Javascript...and plagued with the performance problems you'd expect from Sublime Text, written in JavaScript. There's not really a killer feature that makes me want to switch from the editor I use already. I must be getting old, because "...but in JavaScript!" is not a selling point to me. I don't care what language my editor is written in, except that I'd prefer it to be written in whatever language allows the developers to implement its features in a performant and scalable fashion. (I really love the downvotes for disagreement. Perhaps, if you like the thing so much, you could explain why, instead of just trying to silence people?)

csallen 11y ago
I suspect the primary reason people like the fact that it's written in JavaScript is because a lot of people know JavaScript. That makes Atom eminently hackable.
- timr 11y ago
  Yeah, OK...but Sublime Text is eminently hackable in Python, and it doesn't get the same sort of rabid adoption from Python devs (it's popular, sure, but not more so than vi or emacs).
AlexMax 11y ago
> Perhaps, if you like the thing so much, you could explain why I am an avid Atom user who acknowledges how slow the thing can be. None of the slowness on my end approaches any of the horror stores in these threads, but for me, opening the program from a cold boot takes long enough for the wait to irritate me, the first time I save any file after opening the program takes a second or two, and opening a new window takes a second or two. However, I stick with Atom for a few reasons. First, Atom is like Sublime Text, but nicer. It has real settings pages! It has a built-in package manager! And although you might consider the fact that it's written in what is essentially a web browser to be a downside, there is a huge upside in that packages can create interfaces with that flexibility that Sublime Text simply can't match - compare something like this https://atom.io/packages/php-debug https://atom.io/packages/php-debug with Sublime Text's best-effort https://github.com/martomo/SublimeTextXdebug https://github.com/martomo/SublimeTextXdebug . Not only is trying to assemble an interface out of text buffers not as flexible as a webpage, they also tend to be brittle and break in odd ways if you do any window manipulation on your own - this is actually a complaint I have about Emacs and Vim as well. Also, it just feels like Atom's plugin API is more complete in general - I remember there being a Sublime Text package that required making a copy of your theme so it could add its own styles, and I haven't seen anything similarly hacky in Atom yet. Second, Atom is open source. I had bought both Textmate and Sublime Text and both of those editors had updates slow to an absolute crawl to the point where it felt like the developer had abandoned them. I feel like Atom being open source makes it less likely to be abandoned completely, especially considering how vibrant the community that has sprung up around the editor.

girvo 11y ago

> extremely slow and laden with performance issues I've honestly not experienced this at all; though I'm running Atom/Nuclide with only the Babel language plugin extra.

csallen 11y ago
I think you hit the nail on the head. Slowness in Atom varies so much from person to person probably because it's not in the editor itself, but in the plugins, and everyone has different plugins installed.
- girvo 11y ago
  Right, that's probably the case. And funnily, the reason why I'm so picky about plugins is that I managed to make both Vim and Sublime Text run horrendously via plugin overload.
  - azinman2 11y ago
    Sounds like both should do a better job of telling you which plugins are slowing your system
    - timlyo 11y ago
      Atom has something to help with that: https://github.com/atom/timecop https://github.com/atom/timecop
aeturnum 11y ago
I've tried running atom several times over its history - first for go and again for elixir. Both times I've had the base version of atom with one or two plugins (go-plus / language-elixir & autocomplete-elixir). I found that, even with that setup, Atom was noticeably slower for all aspects of text editing (opening, navigating, typing, selecting, etc). I also found that the plugins did not work as well as the sublime text equivalents I'd been using (though that's not really Atom's fault). I really like the idea of atom, but I've found the practical product less than compelling.

tombert 11y ago

I agree with the first point there. I was pretty excited to try an "open source version of sublime text", but the performance was so terrible I ended up just sticking with Vim. I know people are trying to back away from the console-ui editors, but you cannot deny that,performance wise, it's tough to beat Vim or Emacs.

discreditable 11y ago

Agreed. Atom's performance is it's biggest problem. I've been trying it lately and the startup times are very annoying. I find myself reaching for Notepad++ most often just because I don't feel like waiting.