Atom: Editor window startup is slow | Hacker News Reader

Atom: Editor window startup is slow

github.com

121 pointstosh76 comments

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.

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.

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.

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

    > 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.

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.

400 MB costs less than 2 cents. Is it really worth your time and energy to worry about disk space when you could double the space on your machine for $50?

Space is expensive if you are using an SSD.

And what if we're talking about, say, a proprietary SSD, which is replaceable but you lose your warranty?

Apple's Macbook SSD upgrades are quite a bit more expensive than you're positing.

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.

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

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...

> 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.

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.

Not to sound like a plug for Jetbrains, but for everything IntelliJ does, I find it incredible that it loads so quickly, and the experience is pretty much fluid. VS2008-2013, Eclipse, Netbeans, Qt Creator and others all seem like pigs compared to IntelliJ. The thing that really blew me away and made me a true convert was the jruby+ruby support, and the jruby step-through debugger

I don't know, VS loads pretty quickly and is generally fluid, though it has its shortcomings. Eclipse on the other hand starts up the same way it behaves: slowly. It's much more full-featured than VS or Qt Creator though (at least last time I tried it).

IntelliJ probably manages to do a lot more stuff in the background than its competitors do. I'd argue that concurrency / asynchronicity in large Java applications like that is very complicated, moreso than Javascript-based applications like Atom - so props to Jetbrains for that.

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.

I am the type of developer who uses an IDE. The problem is that I would usually get my work done in Vim while waiting for the IDE to load. After a few instances of finding myself working in Vim with Eclipse loaded and idle in the background, I just stopped opening Eclipse altogether.

As a regular IDE user (Visual Studio, PyCharm, WebStorm) there is no way I would forgive a few minutes loading time. Of the IDEs I use PyCharm is the slowest at perhaps 15-20 seconds to start up, and I consider that barely acceptable. Had it not been such a great product once started up I doubt I'd be as forgiving about its start up time as I am.

> You clearly are not willing to deal with that, and as such are not ever going to be happy.

I'm pretty happy in Emacs. I'm not happy with false dichotomies, like this features/speed tradeoff. There is a real tradeoff to be made between those, but nowhere near the level I've seen in IDEs.

Many problems seem to depend on the way modules/extensions are implemented.

For example, we could implement plugins by allowing event listeners which can run arbitrary, imperative code. However, this leads to redundant computation (multiple "get(foo);" and "set(foo, bar)" calls spread across listeners), increases the chance of plugins conflicting due to race conditions, requiring very conservative scheduling, etc.

An alternative, like a hook/advice system, would have the core performing gets/sets exactly when they're needed, but give plugins the ability to override the return values using hooks (like a dynamic form of decorators). This avoids the redundancy, race conditions and scheduling issues.

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

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.

The speed, and the text rendering for me. Sublime renders the fonts I use better, and it supports bitmap fonts, which I am still fond of.

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

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.)

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.

Whoa, 3 minutes? Is that also from an SSD? Our primary C++ solution in VS (CMake generated) has 35 projects and somewhere between 500 to 1000 source files and it only takes about 10 seconds to open.

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.

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

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

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.

> 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.

I'm running windows.

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.

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

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.

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.).

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."

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).

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".

For an intensely interactive application such as a text editor, performance is part of "make it work". If the screen is lagging behind keypresses, or trivial commands (e.g. the mentioned reordering of tabs) take long enough to wonder whether the program is hung, the basic contract of user interface has been broken. Basing the core of a text editor (not only scripting, as in Emacs, but input, rendering, event handling, data structures) on low-performance technology is as wrong as, say, designing it for single-byte character sets only.

> as the saying goes, "make it work, make it pretty, make it fast"

OT: I've not actually heard that stated before. I've seen "make it work, make it work correctly, (if you have the time) make it work fast"

Maybe I shouldn't be allowed near front-end stuff ;)

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.

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.

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.

Making it usable isn't "premature optimization".

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

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.

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

works fine for me.

Atom is just too sluggish for day to day use.

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

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.

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?

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.

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.

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.

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.

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.

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

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.

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.

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

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

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.

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.

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.

Admittedly I have not. I stand corrected.

> 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.

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.

> Your metaphor isn't really accurate. Atom is not a browser, is a glorified notepad.

Ok, let's try another one:

Atom is an IDE like XCode is an IDE. I don't expect XCode to start up "in the blink of an eye" although I do expect opening a _file_ to take a blink of an eye.

That is the behavior I reported: Atom itself doesn't start up quickly, but loading a new file/window is < 1 second, which I what I'd expect from any editor.

So again, I don't see the issue the OP is referring to. Not to say it isn't there on other machines/configurations, but it isn't an issue for me.

Except the reported sluggish behaviour is for a new window, not a cold start.

> 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.

> 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.

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.

Reply on news.ycombinator.com