Performance [metabug] #5847

alexandernst · 2015-03-05T00:40:49Z

Atom has been growing in features and plugins, but after each release it has been getting slower and slower. It is currently pretty much impossible (dog slow) to edit almost any larger file (even 200kb), with syntax highlight on and long lines (say 300 characters per line).

I see some, supposedly, optimizations (ReactJS, custom rendering, tweaks and what not), but I can barely see any real performance improvements.

I think the entire Atom user base will thank you if you could spend a few weeks performing noticeable tweaks in Atom.

winstliu · 2015-03-05T01:01:10Z

It's interesting that you say that. Most people have actually been reporting that it's been getting faster in the latest versions, especially after the great improvements done by @as-cii and @nathansobo.

So now here comes the normal questioning:
What version of Atom is this? Are the files you're editing still super-slow if you're in safe mode (atom --safe)?

"Large" file performance issues are being tracked in #307 and long line performance issues in #979-do you think this issue should be kept open for another reason?

thedaniel · 2015-03-05T01:27:53Z

after each release it has been getting slower and slower

This is contrary to almost all measurements. I mean, we're not rendering entered text in a few microseconds or anything, but I don't think this is necessarily accurate in the general case. I'm not saying you're lying at all, though - I totally believe that it's getting slower for you and that's troubling because that means there are also probably other people experiencing this! @50Wliu's questions about atom version & safe mode are a good start to helping us figure out why you are seeing performance regressions.

I think the entire Atom user base will thank you if you could spend a few weeks performing noticeable tweaks in Atom.

We have been, and have been getting a lot of positive feedback about performance improvements ;) Let's figure out what's dragging your editor down and fix it!

thedaniel · 2015-03-05T01:38:48Z

Oh, and perhaps a screenshot of the Timecop view (search for timecop in the command palette)

mark-hahn · 2015-03-05T01:44:54Z

I totally believe that it's getting slower for you

It gets slower and slower as you add new packages. Use timecop to find
slow packages and submit issues and/or PRs to speed things up. Most
authors don't take the trouble to use activationEvents or move require
calls into the activation method.

I trim out my least-used packages periodically and Atom gets faster ..
until I add more packages again.

On Wed, Mar 4, 2015 at 5:38 PM, Daniel Hengeveld notifications@github.com
wrote:

Oh, and perhaps a screenshot of the Timecop view (search for timecop in
the command palette)

—
Reply to this email directly or view it on GitHub
#5847 (comment).

alexandernst · 2015-03-05T01:50:11Z

Thank you for the fast reply! First of all, I appreciate the work done by @nathansobo and @as-cii , keep the good job ;)

Now, replying to your questions: This is release 186 and I'm running it in safe mode*. To be exact, I'm playing with latest SugarJS file. (get a copy from here: https://raw.githubusercontent.com/andrewplummer/Sugar/master/release/sugar-full.dev.js )

You'll notice that this in not a compressed js file, so Atom should be able to play nicely with it, but as soon as I open atom (atom --safe) and that file I get around 400mb of RAM usage. That by itself doesn't bother me, I'm on a machine with 64gb of RAM, but this surely will bother the vast majority of people with 4gb RAM.

Anyways, going on with more numbers: as soon as I select, say, 100 lines and start playing with Tab key, I see Atom using anywhere from 5% to 12% of my CPU (which has 8 cores, so this is actually somewhere from 50% to 100% of a core). And this is just hitting Tab to indent 100-150 lines.You can guess what happens when I try to indent 400 or 500 lines (which is a perfectly valid user case)

If I deliberately select a portion of code that, when removed/changed, will cause a major syntax highlight change to a vast portion of code (for example, the beginning of a block comment), I see that 12% CPU spike.

Also, If I hit Ctrl + Space, the suggestions box takes between 3 and 5 seconds.

Resizing Atom's window:
a) feels laggy
b) causes 12% CPU usage (100% of 1 core)

Let's play with another file! I have a 180kb composer.lock from one of my projects. Shouldn't be that much of a trouble for Atom, and yet it literally struggles when I try to scroll fast with the scroll bar on the right size. It uses 100% of 1 core and it eats nothing less than 700mb! (don't forget to set highlighting to JSON when you test this!). I know RAM is there exactly for that reason, to be used, but 700mb for a 180kb file seems completely unreasonable.

Those are just a few examples. Overall, Atom just feels slow when doing things.

*safe mode: I'm a developer, and I do understand why you keep asking users to turn it on. Hell, I do the same things whenever a user reports something buggy in my apps! That is how you differentiate between slow plugins and the editor itself doing strange stuff. But the truth is that it doesn't make any sense from user's point of view. I, as a user, should be able to use Atom with some of the most common plugins (minimap, git, autocomplete) without worrying about performance. Maybe a good strategy would be to actually make a "Top 10" plugins and work with their developers to erase slow codepaths. Just my 2 cents.

And talking about autocomplete (that is autocomplete-plus actually), that only plugin causes major performance regressions. atom-color-highlight is another resource hogger.

mark-hahn · 2015-03-05T02:00:09Z

Others may disagree with my feelings, but Atom is always going to be slower
than an App written in C++. But the flexibility of node/chromium well
makes up for it. For a programming editor only a year old it really has a
lot of useful extensions (mine are the most useful of course). And it will
get faster and faster as Atom/Node/Chromium is tweaked which will be an
ongoing process. And hardware tends to catch up with software.

You were wrong about it getting slower. It is definitely improving
steadily with time.

On Wed, Mar 4, 2015 at 5:50 PM, Alexander Nestorov <notifications@github.com

wrote:

Thank you for the fast reply! First of all, I appreciate the work done by
@nathansobo https://github.com/nathansobo and @as-cii
https://github.com/as-cii , keep the good job ;)

Now, replying to your questions: This is release 186 and I'm running it in
safe mode*. To be exact, I'm playing with latest SugarJS file. (get a copy
from here:
https://raw.githubusercontent.com/andrewplummer/Sugar/master/release/sugar-full.dev.js
)

You'll notice that this in not a compressed js file, so Atom should be
able to play nicely with it, but as soon as I open atom (atom --safe) and
that file I get around 400mb of RAM usage. That by itself doesn't bother
me, I'm on a machine with 64gb of RAM, but this surely will bother the vast
majority of people with 4gb RAM.

Anyways, going on with more numbers: as soon as I select, say, 100 lines
and start playing with Tab key, I see Atom using anywhere from 5% to 12%
of my CPU (which has 8 cores, so this is actually somewhere from 50% to
100% of a core). And this is just hitting Tab to indent 100-150 lines.You
can guess what happens when I try to indent 400 or 500 lines (which is a
perfectly valid user case)

If I deliberately select a portion of code that, when removed/changed,
will cause a major syntax highlight change to a vast portion of code (for
example, the beginning of a block comment), I see that 12% CPU spike.

Also, If I hit Ctrl + Space, the suggestions box takes between 3 and 5
seconds.

Resizing Atom's window:
a) feels laggy
b) causes 12% CPU usage (100% of 1 core)

Let's play with another file! I have a 180kb composer.lock from one of my
projects. Shouldn't be that much of a trouble for Atom, and yet it
literally struggles when I try to scroll fast with the scroll bar on the
right size. It uses 100% of 1 core and it eats nothing less than 700mb!
(don't forget to set highlighting to JSON when you test this!). I know RAM
is there exactly for that reason, to be used, but 700mb for a 180kb file
seems completely unreasonable.

Those are just a few examples. Overall, Atom just feels slow when doing
things.

*safe mode: I'm a developer, and I do understand why you keep asking users
to turn it on. Hell, I do the same things whenever a user reports something
buggy in my apps! That is how you differentiate between slow plugins and
the editor itself doing strange stuff. But the truth is that it doesn't
make any sense from user's point of view. I, as a user, should be able to
use Atom with some of the most common plugins (minimap, git, autocomplete)
without worrying about performance. Maybe a good strategy would be to
actually make a "Top 10" plugins and work with their developers to erase
slow codepaths. Just my 2 cents.

And talking about autocomplete (that is autocomplete-plus actually), that
only plugin causes major performance regressions. atom-color-highlight is
another resource hogger.

—
Reply to this email directly or view it on GitHub
#5847 (comment).

alexandernst · 2015-03-05T02:12:32Z

@mark-hahn No sir. Your reasoning here is completely broken.

I'm not asking Atom to behave like Sublime or Vim. It won't. And I know that. What I'm asking is Atom to be improved in the points I said earlier.
I'm not saying Atom doesn't have features. It surely has. Probably more than most of current editors. That's entirely not the point of this issue.
"Hardware will catch software" <---- this sounds like "let's pray users will have enough money to buy more powerful CPUs and RAM"... just because... I already told here that I'm on a pretty amazing machine (64gb RAM, 8 cores at 3,7Ghz, an NVIDIA SLI). If Crysis can run here with everything on max I can't understand how/why Atom feels laggy (check again my previous comments). My hardware is already up on the right level. It's Atom what is not on the right level.
Chrome/Node improvements won't do magic. Surely they would speed some parts, but relying on the framework to improve to gain some improvements by magic is just a wrong way to look at the things (KDE seems to be pretty good example here, imho).

winstliu · 2015-03-05T02:12:38Z

@alexandernst you may want to subscribe to this issue then (or poke it): #1873.

thedaniel · 2015-03-05T03:56:02Z

@alexandernst a question and a few comments:

What platform are you on? I am assuming Linux of some flavor?
I'm sorry to hear autocomplete-plus is causing serious performance regressions for you, but on the bright side, @benogle and others from the atom core team are working closely with the autocomplete-plus maintainers on API changes and performance concerns because we're considering moving it into core (see Autocomplete Next #4364)
We definitely send PRs and file issues to popular packages when we can, that suggestion of yours above is totally valid. That said, we have our hands nearly full with atom-shell, atom core and all the packages, core or not, that are part of the Atom repo so we do have to mainly rely on community developers to do the right thing in terms of performance. I hope that we can continue to make the core APIs more "performance-proof" so that community packages are less likely to affect general editor performance, but there will always be some variation from package to package, as long as packages have the power to basically do anything to the DOM and the editor processes.
We are absolutely not just calling perf good and waiting for hardware and chromium to catch up. The core team has a weekly call and every week at least one developer spends time talking about where we can shave milliseconds in JS. That said there are some new things in chromium 41+ that we can hopefully take advantage of to improve specific areas of performance like startup time. Also, here is a search for open issues in the @atom org labeled "performance" that may be interesting to you in the mean time.

nathansobo · 2015-03-05T04:03:25Z

We're actively working on a new document model that should address many things you bring up. Nothing I've learned convinces me we can't be competitive with any existing editor, but we need to improve some algorithms at the core of the editor that are too naive. We focused on many aspects early on other than raw performance, and we've learned a lot as a team about how to achieve good performance over time. Now we're in the process of applying those lessons. That we've been able to get away with some of our naive solutions to the degree we have thus far is a credit to the web platform in my mind. When we apply more sophisticated approaches I think it will become evident that web technology is up to this task. Hang in there, or try Atom again when we get further along with optimization. Mainly I just want to say that we feel your pain and we're focused on alleviating it!

alexandernst · 2015-03-05T10:26:15Z

@thedaniel You're right, this is Arch Linux, x64 with vanilla kernel and KDE5.

Nice to hear that you work with external developers! Users will benefit from that ;)

And about the hardware catching the software, that is the right path! Btw, just out of curiosity, what changes in Chrome 41 will help Atom?

@nathansobo Indeed, the technology behind Atom isn't the problem and the proof of that is Brackets, which is based/build using pretty much the same technology/tools and it's fast enough. If Brackets can do it, Atom can do it too!

I'm willing to try this new document model! Is there any issue/branch I can follow for this?

Basically, keep up the good work, but don't forget that Atom can be much faster 👍 ;)

YurySolovyov · 2015-03-05T16:17:04Z

@nathansobo does that new model intent to work well with large(huge?) files?

thomasjo · 2015-03-05T16:48:38Z

@YuriSolovyov Yes. Subscribe to #307.

nathansobo · 2015-03-09T21:01:24Z

Also, atom/text-document.

flying-circus · 2015-05-01T04:35:11Z

May anyone who notices lag issues(for example when scrolling packages list) can try closing all atom windows and reopen it with the following switch:

atom --disable-gpu

In both my computers(radeon 6450 and laptop w internal intel graphics card) gpu acceleration only slows things down.

lock · 2019-01-22T00:29:26Z

This issue has been automatically locked since there has not been any recent activity after it was closed. If you can still reproduce this issue in Safe Mode then please open a new issue and fill out the entire issue template to ensure that we have enough information to address your issue. Thanks!

winstliu added the performance label Mar 5, 2015

alexandernst closed this as completed Jun 17, 2015

lock bot locked as resolved and limited conversation to collaborators Jan 22, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Performance [metabug] #5847

Performance [metabug] #5847

Performance [metabug] #5847

Performance [metabug] #5847

Comments