Hacker News Reader

Comment by wyager | Hacker News Reader

I don't really want more features for Atom. I just want it to be faster. Right now it's incredibly sluggish compared to e.g. Sublime. Is there any hope on this front, or are the performance issues intrinsic?

View on HN

VS Code is also a Chrome window disguised as an app but runs much better, so there's definitely things the Atom/Electron team can do.

I used to think it was faster but for some reason on Linux Mint when I open small source files it just goes berserk and freezes up completely. No idea what would cause it.

VS code runs on electron, so it's really just atom itself, not electron, that must be the bottleneck

This is a great observation and gives me hope for all the other projects built on atom.

It has definitely gotten better and VS Code and Brackets both give hope it can still improve. Actually Brackets all file search is faster than sublime.

I agree. If they could just focus on stability and performance until it's not longer an issue then I would not care about "new features" considering most plugins handle most of what you need anyway.

That is my problem as well. It's just like Sublime.... but slower.

Yea slowness is what led me back to Sublime. I tried for months, I really did.

Is there any chance to use Rust or Go to develop an Atom package? Not for the entire codebase, just for the parts which might be a bottleneck.

Sublime is written in C++ while Atom is written in JavaScript. Atom is going to be slow by design.

Emacs uses 'slow" elisp to implement major functionality, but the critical functionality is written in C. Perhaps that approach could be taken with Atom?

Javascript runtimes these days are plenty fast. You can definitely have a snappy editor and in only rare cases might need C. The issue is probably reducing the browser overhead, i.e. rendering DOM updates and the memory weight of the entire browser stack, etc.

Given that VSCode is fast on the same Electron core also written in JavaScript, I think it's a lazy approach to simply dismiss it as, "Must be JavaScript! Case closed!"

And, there have been editors written in a variety of higher level languages for decades, many that are slower than JavaScript, that aren't (as) slow as Atom. There's more to it than language choice.

I'm convinced it has something to do with the syntax highlighting.

Disable that, and it runs flawlessly on 10+GB files.

I looked into it a bit a few weeks ago but got distracted. It uses regex and many of the statements could be improved. Plus they use a fairly off the wall regex engine that has pretty poor performance but they use it because it supports every damn encoding under the sun.

I think if that can be figured out, the only "sluggish" part left will be startup (which IMO is acceptable at this point, but improvements would always be welcome)

Check this out: http://davidvgalbraith.com/how-i-fixed-atom/

See, I thought that too until I actually tries out Brackets and VS Code and realized that no, it really is just Atom being slow.

It's a browser so I doubt it. On the other hand you get lots of developers and fast feature development/bug fixing.

I see this comment every time an Atom post gets on HN. Are you sure it's not just your computer specs? If Atom continually makes the HN front page then many people must be using it just fine and like it? Personally I'm not sure why we need another text editor of all things, but hey its made in javascript which is hip at the moment.

It's not his specs. Sublime is just that much faster. It also doesn't slowly creep up in RAM usage unlike Atom.

A quad core, 16GB RAM rMBP with SSD should really be able to run a text editor for a 500 line Python file without caret lagging behind typing :/

Sublime can do it easily, Atom still can't. Am I holding it wrong?

No, Atom is just slower.

16GB, 4790k with SSD.

I don't have any lag. Do you have lag with a plain text file? Does this happen with default install no added plugins? I recently was editing a 10M log file with no lag.

I've had problems sometimes with all these editors with occasional bad performing plugins.

My Atom on a 8Gb rMBP with an SSD handles it perfectly fine...

The reason it comes up so often is because it's very noticeable even on late-model systems with SSDs. Just as with Java-based IDEs, the previous target of these complaints, many people tolerate it anyway because they find the features balance out raw speed.

It is certainly slower than Sublime, and is so on well-speced machines. I have machines with i7s, 16gb of ram, and an SSD, and atom still chokes when dealing with large amounts of data. Try multiple selections on large text files and watch it grind to a halt.

Certainly people are falling in love with Atom. It is open source ("hackable editor", as they say at Github), and of course this leads to a much quicker development cycle. Sublime has been criticized because features and updates are few and far between, and there appears to be a reluctance to open-source it.

And Sublime is sometimes slower than VS2015 or even Notepad++ on a similar kind of machine.

Can we convince companies to work on making things run faster instead of just making the hardware faster instead?

" If Atom continually makes the HN front page then many people must be using it just fine and like it?"

This is terrible reasoning. Also if you need a new computer to edit text then something is terribly wrong even more so the more applications adopt such a casual attitude towards sane levels of optimization.

What happens when you want to run 10 applications without having to start and stop them and all require for no particular reason 1GB of ram. Should we just all go buy 32GB of ram and screw anyone with an older machine?

Like others, I have beefy machines and it's still somewhat sluggish. It doesn't bother me as much as others, but I still finding myself typing vscode "blah" instead of atom "blah" for simple file edits that will be opened, saved or looked at, and then closed.

Reply on news.ycombinator.com