Hacker News Reader

Comment by cortesi | Hacker News Reader

I'm making a bit of a habit of chipping in on Atom performance complaints with a counterpoint. I've now used Atom as my primary editor for more than a year, and I have no complaints about the performance. This could be because I'm using OSX on recent hardware - I've noticed that my friends using Linux desktops seem to have more issues than I do.

View on HN

Having both Atom and VS Code installed on recent hardware I can say VS Code definitely feels snappier in multiple aspects. It's hard to believe both editors share Electron roots.

And not to make this an X is better than Y comment, but the much better (in my experience) high-DPI handling with VS Code does the same. I wonder what exactly VS Code does to manage to be the only Electron based application that I've used that scales properly across multiple monitors at different DPIs.

> I wonder what exactly VS Code does to manage to be the only Electron based application that I've used that scales properly across multiple monitors at different DPIs.

It's released by a company that has internal controls on making sure released apps are high-DPI compliant.

It's alright for small files, but whenever I paste in a huge csv or json file it hangs for minutes. And I use pretty recent macbook pro with high specs. This doesn't happen with other editors.

I've found that when pasting in huge files, disabling syntax highlighting makes a big difference. In fact, if you simply open a sufficiently large (I haven't bothered bisecting the size, but a few megs works) xml file, Atom will disable syntax highlighting by default and the performance will be slow but still usable. If you paste in the contents of a large xml file, syntax highlighting is not disabled and the editor either hangs or crashes, in my experience.

Reminds me of old emacs' tricks.

For the gaudiest possible look, then, include the line

(setq font-lock-maximum-decoration t)

Atom should automatically disable syntax highlighting for large files.

Same here, I only get issues after around 100MB.

Most editors start to struggle at such file sizes, which is a shame, but try loading 100mb into Excel. The only editor I found to work nearly instantly is vi; nano takes almost a minute to load large files.

Latest Macbook here, opening files up to 10MB is fine but saving after making any change, even a minor one will cause Atom to hang for a few minutes. In contrast, Sublime has no issues. To be fair to Atom, it has no issues with actual code files in any language; it only struggles with log files and csv dumps. This limitation means I use Atom for most things and Sublime for the heavy files.

Even vi is going to bog down on a file that size if you leave syntax highlighting turned on.

Could be, but it could also have not much (nothing?) to do with hardware.

Anecdotal: back in the late 90s, or early 00s, unlike now, the pc hardware got old really fast in terms of performance. Unlike a classmate of mine I didn't keep up with hardware changes. When I bought my hardware and played games they ran really good, but after a while my pc was not fast enough even for low graphic settings, and the games stuttered really strong with fps probably below 30 fps and around the 20 fps mark (only a guess). At first this was horrible compared to the smoothness of playing games directly after buying the new pc, but after a while I got used to it and couldn't understand why my classmate (which kept up with the new hardware that came out) could not stand to play games on my pc. Later I bought a new pc and could play the games with smooth fps again. When I now played games on slow hardware I could not stand it, just like my classmate before.

Maybe this is (in some cases) also the case with people who have no problems with the performance of Atom.

Personally I also find the performance of Atom could be better (on both Windows and Linux) with a 5820k @ 4Ghz, 32 GByte Ram and installed on a SSD (Crucial MX 100/512 GByte). But I only try it from time to time to see how much better it got compared to my previous try.

I've been using Atom as my primary editor for over a year too, on various Linux distros, and it's been a very smooth experience. The only issue I've encountered is Atom can be sluggish with large (4MB+) files because it attempts to load the entire file into memory instead of streaming it like Sublime Text does for large files. Easy solution to it is to just use a plain text editor (gedit being my preference) to view your logs.

> Easy solution to it is to just use a plain text editor (gedit being my preference) to view your logs.

I had a license to Sublime before Atom was even released, so that's what I use :-) I used Atom for at least a year just to support the open source aspect of it (I do spend most of my time in RubyMine these days)

Yeah, I use atom on an mbp 2013 as well as a Linux desktop, and it runs fine. I dont have perf issues, even when opening a large 10k+ line javascript file (a built lib package, when I'm debugging occasionally). Of course, most of my source files are 100 - 1000 lines long.

I have a pretty good computer but atom is pretty slow, crashes often, and all that's with little to no plugins. vS Code on the other hand I've never had crash and handles lots of files with ease.

Tried Atom and it was a real memory hog on Windows - need to go back and try this version, but do enjoy using Caret for lighter touch work that doesn't need a full IDE (or at work where Chrome extensions are allowed, but installs aren't).

Thanks, I installed Caret-T[0], will play around with it. For those not interested in the fork and javascript Intellisense, have look at the caret website[1].

[0]: https://chrome.google.com/webstore/detail/caret-t/agiednhnlg... [1]: http://thomaswilburn.net/caret/

Reply on news.ycombinator.com