
Atom: Editor window startup is slow - tosh
https://www.github.com/atom/atom/issues/2654
======
keerthiko
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.

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

------
hartror
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...](https://github.com/atom/atom/issues/2654#issuecomment-50137294)

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

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

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

~~~
snarfy
I'm running windows.

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

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

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

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

~~~
icefox
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_
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".

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

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

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

------
mosselman
Atom is just too sluggish for day to day use.

------
lobster_johnson
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/...](https://github.com/atom/atom-
shell/blob/master/atom/browser/lib/rpc-server.coffee)

[2] [http://shoesrb.com](http://shoesrb.com)

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

------
tosh
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?

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

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

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

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

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

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

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

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

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

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

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

~~~
skrebbel
Admittedly I have not. I stand corrected.

