News for hackers. Stuff that matters.
Re:Optimizing an Important Atom Primitive by baldfat on Tuesday June 16, 2015 @02:26PM (#9727790)
Atom is still a hog on my main programing machine. It makes it unusable for me still.

It is an OLD i3 Dell from 6 years ago desktop.

Re:Optimizing an Important Atom Primitive by davnicwil on Tuesday June 16, 2015 @02:40PM (#9727903)
Genuinely intrigued to keep seeing this persistent complaint with Atom.

I've been running it for ages on a mbp with 2.6GHz i5/8Gb RAM. It's lightning fast.

Very occasionally it will appear to be hogging CPU - typing is slow and it might hang for a couple of seconds when you're navigating around. This only seems to happen when I've had it running for days if not weeks without a restart. I just restart it and it's back to being lightning fast.

I really like Atom and would be pretty upset if it stopped working well for me, so would be curious to know what kinds of things people suspect cause it to have issues.

Is it just that my machine is powerful enough to not notice, and it's only really a problem on less powerful machines? I don't run many plugins, and installing many of these tend to bring it down? It runs well on OSX but not other platforms?

Re:Optimizing an Important Atom Primitive by maxbrunsfeld on Tuesday June 16, 2015 @03:03PM (#9728071)
Packages can definitely have a significant impact on Atom's performance. You can observe all kinds of events, and binding a slow handler to certain events like text changes and cursor movements can make the editor feel sluggish.

It's important for Atom's extensibility that these kinds of events are provided, because it allows many major editor features to be implemented as separate packages, but it means that naively-implemented packages can really slow things down.

Many Atom packages are pretty new, and their authors may not have put a lot of effort into optimization yet. In the past few months, the team has put a lot of effort into stabilizing and solidifying our APIs. We're hoping that now that the APIs are stable, the package ecosystem will really start to mature.

Re:Optimizing an Important Atom Primitive by seanp2k2 on Tuesday June 16, 2015 @04:11PM (#9728416)
What about a built-in mechanism to let you inspect what plugins are causing the most delay e.g. During a measuring period? Is that already a thing?
Re:Optimizing an Important Atom Primitive by maxbrunsfeld on Tuesday June 16, 2015 @04:22PM (#9728472)
The best tool for that (and any profiling in Atom) is chromium's built-in profiler. See the flame graphs in the blog post.
Re:Optimizing an Important Atom Primitive by grayrest on Tuesday June 16, 2015 @04:37PM (#9728542)
Editing text in Atom isn't instantaneous for me like MacVim or Sublime but the typing latency is low enough to not bother me (roughly 1-2 frames), roughly the same as the jetBrains family of IDEs. When I load up atom-typescript, typing latency takes a noticeable hit and drops to the annoyingly sluggish range (~3-4 frames). This is on a 2012 mba with a 1.8GHz i5. I also have 2-3s of startup delay and frequently have a half-second to second delay when opening a file. None of these are terrible but they're all noticeable.

I suspect that people who complain about speed are either on lower end hardware or are comparing it directly to a native editor directly and consider any typing latency at all to be unacceptable.

Re:Optimizing an Important Atom Primitive by baldfat on Wednesday June 17, 2015 @08:28AM (#9731317)
I am talking about 5 seconds a word speed. I type and it takes 5 seconds for my word to show up on the screen. I have default plugins nothing else installed.
Re:Optimizing an Important Atom Primitive by matwood on Tuesday June 16, 2015 @04:02PM (#9728362)
I haven't had any speed issues with Atom either. It has worked well for me overall. What I don't get is the people who say Atom is slow and then say Intellij is fast. I'm not sure how I can take them seriously.
Re:Optimizing an Important Atom Primitive by JadeNB on Tuesday June 16, 2015 @10:08PM (#9729755)
> Very occasionally it will appear to be hogging CPU - typing is slow and it might hang for a couple of seconds when you're navigating around.

Do you literally mean that it hangs for a couple of seconds? That seems like an eternity, especially if it happens during navigation.

Re:Optimizing an Important Atom Primitive by davnicwil on Tuesday June 16, 2015 @10:29PM (#9729807)
Literally, and in this state it is totally unusable. But let me emphasise this happens very rarely, once every couple of weeks maybe. When it does I just kick it over and it's fine.
Re:Optimizing an Important Atom Primitive by mirekrusin on Tuesday June 16, 2015 @04:58PM (#9728650)
Maybe try removing all plugins and retry. It's possible that one of them is responsible for this slowdown. This was the case for me couple of months ago.
Re:Optimizing an Important Atom Primitive by thedaniel on Tuesday June 16, 2015 @05:29PM (#9728820)
Running `atom --safe` will start the editor with only bundled packages activated.
Re:Optimizing an Important Atom Primitive by hugh4life on Tuesday June 16, 2015 @02:29PM (#9727819)
When was the last time you tried it? Atom works fine on dell computer with Intel duo core 2 from 7ish years ago.
Re:Optimizing an Important Atom Primitive by vladikoff on Tuesday June 16, 2015 @02:32PM (#9727849)
I like Atom! However, sadly a simple regex search can kill it in 5 seconds.
Re:Optimizing an Important Atom Primitive by mrbogle on Tuesday June 16, 2015 @02:37PM (#9727884)
This is exactly the case that is better as a result of these optimizations.
Re:Optimizing an Important Atom Primitive by oneeyedpigeon on Tuesday June 16, 2015 @02:46PM (#9727948)
It's still much slower than, for example, Sublime Text. A search for a single letter [1] in a ~5,000 line file occurs instantly in ST, but takes about 1 second in Atom. It's not much, but it's very significant from a UI point of view.

[1] I know such a search is ridiculous, but both editors perform search-as-you-type, although atom does attempt to delay that if you type quickly enough. Anyway, it's just an example to demonstrate the speed difference.

Re:Optimizing an Important Atom Primitive by crucialfelix on Tuesday June 16, 2015 @04:05PM (#9728377)
Just like in emacs and vim there are plugins that let you use ack and grep: https://atom.io/packages/atom-fuzzy-grep

The built in search is slow (for now), but they have been steadily making gains and use performance testing to measure progress.

Re:Optimizing an Important Atom Primitive by maxbrunsfeld on Tuesday June 16, 2015 @02:56PM (#9728020)
There's still some major algorithmic optimization to be done regarding the time it takes to run the find-and-replace search. The optimizations discussed in this blog post were more focused on the performance of editing the buffer in the presence of large numbers of search results.
Re:Optimizing an Important Atom Primitive by oneeyedpigeon on Tuesday June 16, 2015 @03:25PM (#9728179)
Right. Don't get me wrong, the article was interesting and I appreciate there's a lot of hard work going on. I really hope atom is a success because an open source equivalent of Sublime Text would be very welcome.
Re:Optimizing an Important Atom Primitive by ZenoArrow on Tuesday June 16, 2015 @05:18PM (#9728759)
>"an open source equivalent of Sublime Text would be very welcome."

Good news, it exists. If you know Go it's possible to see it sooner: http://limetext.org/

Re:Optimizing an Important Atom Primitive by drudru11 on Tuesday June 16, 2015 @02:28PM (#9727814)
What OS are you running on the Dell?
Re:Optimizing an Important Atom Primitive by baldfat on Wednesday June 17, 2015 @08:29AM (#9731324)
OpenSUSE 13.2 with a tiled window manager and no other Desktops installed.