Atom: Editor window startup is slow

https://www.github.com/atom/atom/issues/2654

by tosh • 12 years ago

121 76 12 years ago

This is the reason I stopped using Atom. It seems great but the performance was terrible, especially next to sublime.

nclzz• 12 years ago

Same for me, Sublime is faster and that give you an awesome sensation. I used Atom for a couple of weeks three months ago, i stopped the same moment i reopened Sublime.

hartror• 12 years ago

The best comment is batjko's about how Atom is stuck in no mans land between text editor and IDE. One you expect to open near instantly, the other you'd forgive for a few minutes of loading.

https://github.com/atom/atom/issues/2654#issuecomment-501372...

colinramsay2• 12 years ago

But comparing it to Textmate and Sublime is entirely fair, and both of those (as per the comments in the thread) are faster.

rattray• 12 years ago

Agreed. Atom seems intended to be a drop-in replacement for Sublime. I tried it out again a week or so ago and found it almost at parity. The speed issue mentioned here is one of the biggest reasons I went back to the closed-source Sublime.

micampe• 12 years ago

I don't use Atom so I can't compare directly, but from those comments even Xcode sounds faster.

bhouston3• 12 years ago

Even though I am a sublime user for some tasks I still use Visual Studio. I have to say that Visual Studio actually has a very fast start-up time -- thus it is a bit of a myth that IDEs have to start slow.

I just ran 2008 and 2012 and the second time they load (I prewarmed the caches), they load in about 1 second. With a cold cache 2008 takes 2 seconds although 2012 seems to take 15 seconds (which is slow.)

(Tested on a fairly high end machine, you results may differ.)

maccard• 12 years ago

I opened 2012 and 2013 and they're almost instant on my machine(high end machine). Opening my main solution for work is roughly 3minutes on same machine, which would be nice if it could be done faster, but that's not going to happen I suppose.

chriswarbo3• 12 years ago

the other you'd forgive for a few minutes of loading.

No I wouldn't. What features do IDEs have which makes "a few minutes" a forgivable startup time (which I'll arbitrarily define as "time until key presses cause characters to show up on screen")

Especially in a world where Web apps are "slow" if they take a few seconds to load, and a bunch of work is going into replacing OS init systems to get their boot times under 10 seconds.

I didn't forgive Eclipse and Netbeans for their slugishness and bloat (they're the only programs I've seen with progress bars for exiting!). I've since switched to Emacs, which straddles the divide between text-editor, IDE and operating system.

Even loaded with extensions, written in LISP, running in a single thread, it loads in a few seconds.

apalmer• 12 years ago

I think his point is that if you were the type of developer who uses an IDE, you are willing to accept the slow start up time. You clearly are not willing to deal with that, and as such are not ever going to be happy.

Some tools take a while to warm up, use them or don't.

Igglyboo3• 12 years ago

Yea a few minutes is ridiculous. IntelliJ takes max 30s for me to start and it's pretty heavy, I can't imagine waiting more than a whole minute. That's just unacceptable.

Igglyboo3• 12 years ago

I completely agree, atom takes about 2s to open on my machine and it drives me insane. IntelliJ on the other hand takes about 15-30s, depending on the size of the project, to open and it doesn't bother me at all. Maybe because IntelliJ in my mind is a full fledged IDE and atom is not, it also has a splash screen which helps in my opinion.

EDIT:

I'm on a brand new macbook pro with 16gb ram and a 512gb ssd and it takes 2 seconds. It takes about 10 seconds on my old chromebook.

treehau52• 12 years ago

I would check into that startup time for Intellij -- I am similarly on a brand new macbook pro (16gb ram, ssd) and my largest project takes a few seconds tops. Only the maven auto-importer has ever slowed me down to ~10 seconds, but by then the editor was fully loaded.

OK I see your edit now

venomsnake• 12 years ago

IntelliJ, VS and even Eclipse load in under 5s.

jongold• 12 years ago

But still no acknowledgement that on Retina MBPs it spins up fans and uses >100% CPU?

lookingsideways• 12 years ago

I had this issue with older versions but I've been using Atom as my primary editor on a rMBP for the last couple of months with no CPU usage issues.

oe• 12 years ago

Works on my machine. Maybe you have some bad plugin?

grandalf2• 12 years ago

works fine for me.

skrebbel2• 12 years ago

I really don't understand the problem. If your concentration span is that short, what are you doing writing software professionally?

How often do you start up an editor per day? If the editor offers tools that save you more time than that, you won.

It's like refusing to use a chainsaw instead of a handsaw because it's a 2 minute walk to get it.

EDIT: I talked before my turn. I thought this was just about initial startup, but apparently it's about each editor window. Thanks schrodinger.

schrodinger• 12 years ago

Have you used it? It's not just start up that's slow, it every time you open a new window. So if you go to type a git commit message, 5 second lag until it shows up. Double click a text file (after atom is already open), 5 seconds.

If it was just the initial startup, I'd be compelled to agree with you.

skrebbel2• 12 years ago

Admittedly I have not. I stand corrected.

wiremine2• 12 years ago

How often do you start up an editor per day?

That's what I came here to mention. I've been using Atom as my primary editor for a month or so now, and I've never noticed the slowness.

After I read this post, I did a test:

Launching a file when the editor isn't in memory:

atom filename.js

This takes around 4 seconds on my Mac Air.

Launching a file when the editor is in memory:

atom filename2.js

This second one takes < 1 second.

I could see the OP having a point if the _second_ version was taking a while: this would be the equivalent of opening a new browser tab in 4 seconds. But opening an entire browser in < 1 second? I don't really expect that on my mac.

riquito• 12 years ago

Your metaphor isn't really accurate. Atom is not a browser, is a glorified notepad. The fact that internally it uses VP8 or anything else doesn't matter (neither should) to the user.

The user expect it to open in the blink of an eye, no matter what, and it can be done for this kind of program as alternatives in the same league show. If it isn't possible at all with the underlying technology, that was a bad technological choice. However I wouldn't worry so soon, there is a lot of space to optimize, the project is young.

Dewie• 12 years ago

How often do you start up an editor per day?

Well, the issue submitter wrote:

I usually open Atom using the Shell command "atom [filename]"

So it might be that he opens up the editor many times a day.

Anyway, I don't think asking for a snappy editor start up time is much to ask for, in this day and age. And if some editor doesn't offer that, there are enough other editors that will offer fast start up time as well as features that are associated with power editors.

I sometimes can start up my editor (Emacs) many times a day. Maybe I have an Emacs up for some editing on one workspace, but I need to open it in another workspace, because it fits better in that workspace. Not to mention that some programs uses my $EDITOR variable to launch Emacs when I need to edit something. That's another program start up, and I'll be damned if I have to wait 2 minutes to edit for my editor to start up just so that I can edit a git commit message.

In my case, I guess I might be able to set up an Emacs daemon, if start up time and stuff like that is ever an issue (what isn't possible in Emacs, with enough effort?). But if any editor offers something like that as a solution so slow start up times, it better be straightforward to set up.

pmontra• 12 years ago

Another emacs user here. I don't know which version of emacs you use and on which OS but this is what I can do with emacs 24 on Ubuntu (X11, Gtk).

Open another window of the same editor (a frame): File, New Frame or C-x 5 2 and then move it to another workspace. This seems quicker and more efficient than opening the whole editor again but maybe this isn't faster in your setup.

Emacs starts a server if you include (server-start) in the .emacs file. Then you can open files in that emacs like this $ emacsclient -n file I have a alias ec="emacslient -n" in my .bashrc The -n is to make the command terminate without waiting for the buffer to be closed in emacs. Maybe you want to do without the -n if you use emacs inside other programs (e.g. for editing the log messages in git) but I usually use vi for quick edits.

Unfortunately running two emacs with one server each doesn't ends well so the emacs server is almost bound to using new frames in multiple workspaces.

Igglyboo3• 12 years ago

How often do you start up an editor per day?

Probably 50 to 100 times.

Also it's not just the startup time, atom in general is slow but most of the work being done is on the speed of the editor and not startup time. While I do agree that the actual functionality is more important than startup, it seems like they don't really care about the startup time at all.

tosh• 12 years ago

I wonder what they could do to work around this hypothetically (ignoring whether it is a valid priority or how hard it would be).

Would it be possible to immediately 'show' something (ideally the content of the file) until the whole editor/browser runtime starts up?

bhouston3• 12 years ago

Have a hidden atom loaded and all initialized and then fork it for each new window -- then it is all preloaded and ready to go. :) Might be a bit tricky to get a unique environment each time, but then add an init function to do that.

Or have an on computer startup process (yuck), that basically warms the atom cache for you. I know Microsoft Office does this or did this.

mosselman• 12 years ago

Atom is just too sluggish for day to day use.

keerthiko2• 12 years ago

3 things made me drop Atom:

1. The slow startup time in question

2. The huge editor software file size. I am not leaving 400mb for "yet another text editor"

3. I had become very dependent on some Sublime plugins for my work and the Atom counterparts were a long ways off being up to par.

The thing that first made me excited about atom was that being built around Chromium I thought we could finally have an editor with a nice Chrome-like web view with real-time update built into it, as a tab or something.

However, I noticed a thread on it in Atom (can't find it now), and it sounded like the core of Atom's security prevented such a thing from ever being built, so it would remain an unfulfilled desire. Oh well.

rplnt• 12 years ago

Yeah, the size was staggering. And prebuilt packages for one platform (now two)? Haven't even tried it...

sagichmal• 12 years ago

    > 2. The huge editor software file size. I am not leaving 
    > 400mb for "yet another text editor"

I don't know why you'd care about this, besides reasons of dogmatic principle. Disk is the cheapest thing in the world. Any benefit that can be had at the cost of larger artifact size, especially for things like consumer applications, should be taken, IMO.

Fastidious• 12 years ago

It adds up. More and more applications are that fat. My system drive is 1 TB, and I am a point in which I need to judge which application is worthy of taking space. I agree that 400 MB for an editor is a tad too much.

keerthiko2• 12 years ago

Theoretically, space is cheap. But space is precious on a 128gb ssd macbook air.

I am pretty economical with space, I don't store media on here, it's almost entirely dev tools and code projects. And I do not want a piece of software that takes 400mb without providing me significantly more value than what my 30mb (Sublime Text) one. I don't care about media being large, or backups taking a lot of space, or installers being big, since I can shove those on an external.

But I'm obviously not going to do that with any dev tools. Any tool that cannot justify it's size cannot live on my internal drive, and if it ain't there I'm not using it.

freebs• 12 years ago

Not only the start up time, it seems to hog memory and bog down my Macbook Air (4GB) after using it for awhile. I'm not entirely sure if it was the length of time I had Atom open or the size of the project. I usually have Chrome running with a small Vagrant box. After a few hours it was unbearably slow to even switch between open files.

I closed Atom and my memory pressure dropped considerably. Installed Brackets and the pressure is still low even with Chrome and a box running yet.

This probably isn't an issue for people with 8+ GB of ram though, unless it actually has a memory leak.

sdegutis• 12 years ago

Well duh, it's built on web technologies. These are probably the most bloated, inefficient, and memory-hogging things humanity has built on a computer to date.

Honestly, nobody who adopted Atom should ever be surprised by any single aspect of its sluggishness.

freehunter• 12 years ago

Installing Brackets is probably the best thing I've ever done in my entire web programming career.

knowaveragejoe• 12 years ago

After trying Atom, I was thrilled with the concepts I was seeing. That said, I've been waiting for it to mature a bit before using it full time. Based on these comments it looks like it might be a while longer.

kachnuv_ocasek2• 12 years ago

Why is this on the front page? It's a well known fact and I wouldn't expect much from an alpha-stage software (premature optimization, etc.).

theCricketer• 12 years ago

Maybe I'm a noob, but its such a nice conversation. Real interest to improve a product. And a busy engineer taking time to help onboard the new comer to the Atom project. Pretty cool IMO.

ceejayoz• 12 years ago

Making it usable isn't "premature optimization".

icefox• 12 years ago

It really depends on your expectation. Back when I created the Arora browser (2008) one common complaint was how starting up a new browser (firefox,ie,safari) took so long so no one should have cared about the startup speed. But as a developer I cared because I was also a user and regularly kept the load time under a second and much more closer to 100ms (with Qt in memory). As you approach commodity status (like browsers were back then) load times are one of the easy things that cause you to lose users. It was a pretty basic optimization problem. Defer loading of assets that are not needed, tricks like showing something to the user even if they can't actually interact with it for another 15ms, removing expensive computation that can occur seconds/minutes later (does the disk cache really need to check for expired stuff right now on startup?) This was regularly tested with a "big data" such as a large disk cache, a history measured in years, etc. After those architectural decisions were made then it was basic profiling and fixing hotspots, improving algorithms and going beyond my application I went through and fixing issues in underlying libraries such as in Qt where I made fixes which not only improved my startup time, but every single Qt application.

Startup speed matters, sometimes a lot, sometimes not so much. It is both interesting because optimizations are a common problem in our field and the different approaches that can be taken are interesting to discuss, but it is also interesting taking a look at how this particular project cares about startup speed and what they have decided to prioritize over it (the social / project management aspect).

Cthulhu_2• 12 years ago

Your post reminds me of when Chrome was first released, and how startup time (and speed in general) was one of their primary concerns. They had (and probably still have) a whole suite of performance tests that, amongst other things, measure startup time.

With that in mind, if they didn't have those optimizations, Atom would probably be an order of magnitude slower to start up than it is today. It's all a matter of non-functional requirements and priorities, I guess.

On the other hand: as the saying goes, "make it work, make it pretty, make it fast" - which can be interpreted in various ways, like "working software is more important than fast software" (aka avoid premature optimization), and "a well-designed application is easy to optimize".

userbinator• 12 years ago

I think it's an interesting demonstration of the rather sad fact that despite hardware today being many, many orders of magnitude faster than what was around e.g. 2 or 3 decades ago, it seems software has only gotten increasingly inefficient, so there's a huge amount of processing power and - if humans are being kept waiting, their time - being wasted because of this; this is a text editor, albeit a featureful one, whose resource consumption is disproportionate to its capabilities. It's what happens when countless abstractions are piled upon one another, with little regard for the consequences of doing such a thing.

Even Emacs is smaller, and it's just as if not more customisable/featureful.

Here is a nice rebuttal to that "premature optimisation" myth: http://ubiquity.acm.org/article.cfm?id=1513451

From personal experience, by the time a system gets too big/slow, the inefficiency is usually distributed throughout so that it becomes more difficult to single out one component that's causing it, and there is no easy way to optimise such a system short of redesigning and rewriting it - it can be said that the problem is because "the whole is bigger than the sum of its parts."

erikb2• 12 years ago

This is a question I never understand. What ends up on the front page is no single persons decision. If enough people upvote something in a short enough time frame it will get on the front page. You know that, and you also know that it's not logical process. Thus sometimes an article ends there that might not make sense there at all.

kachnuv_ocasek2• 12 years ago

Of course by "why is this on the front page?" I actually mean "why are people upvoting this?" The latter seems a bit too aggressive even for me, though.

grandalf2• 12 years ago

In my opinion, if you're starting atom more than a handful of times per day you're using it incorrectly. Try nano instead!

colinramsay2• 12 years ago

And that's just your opinion. Other people, myself included, use their editor in a different way and slow startup time is an important consideration.

erikb2• 12 years ago

Even that could be handled, by the editor getting out of your way when you don't need it. I'm not an expert, neither in Atom, nor software design on that level, but I suppose a web based editor could have a server running in the background, doing the hard work, and a lightweight client that starts up fast. And there might be a million other ways to allow people fast start-close-interactions without actually starting or closing the software all the time.

Therefore saying that you should use a software in a certain way is not really a good argument. It's possible to adapt the software to the user.

snarfy2• 12 years ago

I just installed it for the first time, opened a few files and it seemed OK, then I read the comments here.

Next I tried rearranging the tabs around and it took seconds? for the drop of the drag-n-drop motion to register.

This is why I lol about everything being re-invented in the browser and rewritten in javascript. Just because you can doesn't mean you should.

mikewhy• 12 years ago

Next I tried rearranging the tabs around and it took seconds? for the drop of the drag-n-drop motion to register.

Not seeing that, at all. What you've described just sounds like the default delay OSX puts on tap/three-finger drag motions though.

snarfy2• 12 years ago

I'm running windows.

kclay• 12 years ago

Couldn't they do what IntelliJ does and spin off some threads to handle the work in the background ?

jeffreyrogers• 12 years ago

The problem is really its architecture rather than its implementation. The only way to fix the performance aspects of Atom (slugishness, RAM and CPU usage) is to start over and redesign it from a perspective of performance.

ianstallings• 12 years ago

I leave it open for this reason. But honestly most of my more robust editors are slightly slow to start and I keep them running if I think I'll need them. If I need super quick and light I fall back to vim.

croddin• 12 years ago

Developing on fast computers with SSDs can increase productivity, but I wonder if during some development phases of some apps, you should use a slower computer to "dogfood" on.

Dolimiter• 12 years ago

This was always going to happen, Atom was always doomed to fail.

Why was that technology stack used to develop Atom? A browser window to render a text editor?

If Atom wanted to take over the world, it should have chosen a technology stack that made it run AT LEAST as quick as Sublime Text. Instead we got Eclipse. Therefore, it's never going to get traction outside a niche.

LESSON LEARNED: Choose a technology stack that benefits the end user, not one that suits the developer of the software.

lobster_johnson• 12 years ago

Atom's tech stack choice is interesting. I have had several Mac app projects in mind where I really desired something more lightweight and webby than Objective-C, and toyed with the idea of using Node-Webkit or Atom Shell.

But I have always put it off:

- The performance challenges are daunting. For complicated, heavily data-oriented UIs like Atom's that require low latency and efficient memory usage, it's nowhere close to native.

- I'm growing increasingly tired of dynamically typed languages. What I want is to be able to implement native GUI code in a fast, statically typed language (ObjC is fine for this); and then write high-level logic in a scripting-type language. But:

- The divide between native (ie., the shell) code and app code is very hard. Atom Shell actually relies on a special IPC mechanism to let the JS code talk to the native shell, and all the IPC calls have to implemented manually [1]. Surprisingly, there isn't anything like MacRuby/RubyMotion's Cocoa bridge.

I'm intimately familiar with ObjC/Cocoa, and it's a great language and framework, but I feel like as UI framework go, it's a bit antiquated; the "amount of code to productive, visible UI effect" ratio is very high. Way too little of my code ends up being actual app code, and way too much ends up being non-reusable, hand-coded, pixel-perfect-tuned logic to handle things like reshuffling UI components with animation. As a former Delphi developer, it's amazing to me that GUI development is actually harder today than it was in 1998.

Just look at Shoes [2] for how simple a UI framework could be. It's not something I would/could use myself, but it certainly gets a bunch of things right.

[1] https://github.com/atom/atom-shell/blob/master/atom/browser/...

[2] http://shoesrb.com

wldcordeiro• 12 years ago

The other issue I have with Atom that really bothers me is its text rendering. I can not understand why a font that is usable and readable in Sublime Text at 13pt is terrible in Atom. I have to have my fonts set to 3-4pt higher than what I use in Sublime.

wnevets• 12 years ago

Its slowness is what has stopped me from even considering dropping sublime. Hopefully once it hits beta it will be alot faster.

ackalker• 12 years ago

This is a snippet of email I sent to a friend just a few days ago. Besides the slow startup, I think these numbers speak for themselves...:

    $ sudo ps_mem
     Private  +   Shared  =  RAM used       Program
    
    [...]
    412.0 KiB + 137.5 KiB = 549.5 KiB       vi
    [...]
     12.2 MiB +   2.7 MiB =  14.9 MiB       gvim
    [...]
    968.9 MiB +  94.3 MiB =   1.0 GiB       atom (7)

That's with no file loaded in any of the editors, gvim brimming with plugins, Atom freshly installed. Sad, really.

Atom: Editor window startup is slow

Related Stories