Hacker News Reader

Comment by nickpeterson | Hacker News Reader

Doesn't indicate perf improvements... Not trying to troll, but that surprises me given the large number of complaints about performance.

View on HN

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.

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.

Atom should automatically disable syntax highlighting for large files.

Reminds me of old emacs' tricks.

For the gaudiest possible look, then, include the line

(setq font-lock-maximum-decoration t)

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/

The performance problems on a clean Atom install are incredibly vexing. Microsoft's Visual Studio Code is built on similar foundations and has great performance, so I don't think Atom's performance problems are fundamental.

Yeah, I've been really impressed with how snappy VSCode is.

Visual Studio Code is a totally different foundation. The only shared piece is the Electron shell for embedding Chrome.

That's sort of the foundation though right? The editor built into the electron app is completely different, suggesting that atom is theoretically able to achieve similar performance.

I haven't used visual studio code myself, but does it use a mix of JavaScript and HTML to render and process the text? If so then isn't the major differences the algorithm choices for rendering and editing text?

> Microsoft's Visual Studio Code is built on similar foundations

This is my understanding of things:

- Electron is built on top of Chromium, where the technology was mainly driven by Google and their engineers.

- Vscode is based on Monaco which Erich Gamma and his team spear headed.

- Atom is based on work done by GitHub.

The analogy would be they both use Honda engines, but Microsoft appears to be able to use Honda's engine way more efficiently than GitHub.

No this is pretty wrong. They are both built on Electron which is just the window shell hosted in Chrome. The actual text editors are completely different code bases that have nothing to do with each other.

The better analogy would be they are both built using Honda doors, but they each have completely different engines.

The point is that if Electron itself (i.e. using Javascript and the DOM) was the issue then both would suffer.

You might want to tweak the wording a bit - it reads like you're comparing Monaco to Electron, as if it were another app framework based on Chromium.

Since both VS Code and Atom use Electron as a base, so if the basic premise of using JavaScript + the DOM to render a code editor / IDE were flawed (i.e. it could never be performant), then both systems would be having issues.

This is what I was trying to state. If performance issues were fundamentally tied to the use of Electron, then you would see that manifest itself in both packages.

Oops, I thought you had written sdesol's comment [1]. Sorry.

[1] https://news.ycombinator.com/item?id=11493311

Yeah, Atom is really my favorite editor at the moment in terms of features and add-ons but is totally unusable for me due to various performance issues. Not only does it choke on large files but something like a full-project search can take upwards of 30s to finish while Sublime Text finishes it in about 2-3s. I'd like to switch personally, but I can't until some major performance improvements happen. YMMV.

Yes, search is really slow. But atom-fuzzy-grep is near instantaneous even on large projects. Uses ag pt ack or grep

https://atom.io/packages/atom-fuzzy-grep

The nice thing about Atom is that you can replace anything that isn't performing.

What kind of computer and OS are you using?

Late 2013 Retina MBP w/ 16GB of RAM

Unless you tell someone your OS and hardware, it's really not helpful for people to decide, or even address the problems.

Does Atom use a lot of ram or cpu? I've got a 2 year old Mac Book Pro with 16 GB RAM and an SSD. I downloaded Atom 1.6 after the announcement and leave it open to maintain my notes and I haven't noticed any performance problems with a couple dozen files. I might try to use it for another project once I evaluate the plugins.

You shouldn't need a $2000 laptop to run a text editor.

No one said you did. I simply stated what I owned and explained how I use it, and how it performed.

I imagine the same performance as my 2 year old laptop is equivalent to $500-$800 desktop today.

But you will most likely have it anyway.

Speak for yourself. My primary computer is a $200 laptop.

ok, try Atom and report back. The guy who was complaining had projects of several thousand files, some of which were 50,000 line xml files.

yes, I have a few thousand files, some of them are 50k+ line XML files. Sublime still searches my full project in many magnitudes of less time that Atom does. I use Atom for my small toy projects as well.

I don't know when the perf improved, but it definitely has recently. In the past month I downloaded Atom on OS X (for the third time) to see if the perf had improved and I was impressed! I added a huge project's folder and indexing was done insanely fast (iirc less than 30 seconds). I don't really have a need for Atom at the moment since Sublime Text exists, but I might recommend it for new programmers since it's free + hackable.

I think it's gotten much better this year. It used to be somewhat slow (especially on large files), but it's alright now. Still room for improvement though.

Many devs could get a faster computer, too. I'm considering getting a Surface Book.

I've been using Atom for over a year and haven't had any major performance problems. Luckily for me I don't have to regularly access code files that are megabytes long but I can see why not being able to do so would be annoying.

They had decent performance improvements in recent major releases. It's pretty good now, except for the initial boot time. Takes ages to launch it. But after that, runs smooth on my laptop.

Reply on news.ycombinator.com