Improve startup time

[benogle]

Status: This is an ongoing effort.

Via @kevinsawicki

The current plan is to investigate what is slow on startup, optimize it, and then investigate concatenating all the CoffeeScript requires to save eval time on startup.

Merged Changes

Times below are were taken with a Macbook Pro on OS X 10.8.5 with 2.6 Ghz Intel Core i7 processors and 16 GB of memory

• atom/less-cache@dbddce5
  • Saves ~40ms when starting Atom with a fully warm Less cache
• #3453
  • Cuts browser process launch time by ~33%
  • Saves ~60ms on startup
• #3470
  • Cuts time taken to apply stylesheets by ~66%
  • Saves ~40ms on startup
• atom/wrap-guide#16
  • Saves ~10ms on startup
• #3519
  • Saves ~250ms on startup
• atom/tree-view#219
  • Saves ~200ms on startup for large projects.
• atom/status-bar#35
  • Save ~30ms on startup
• atom/tabs#82
  • Saves ~15ms on startup
• #3917
  • Reduces number of files read at startup
• #3761
  • Caches requires across all installed packages and speeds up require resolution

[YurySolovyov]

You can also take a look at atom/atom-shell#251, maybe you can get some speed there.

[ilanbiala]

Looks really awesome so far. Are these changes available in the latest releases of Atom, or are they only going to be available in 1.0?

[50Wliu]

The listed changes have already been merged, and I'm pretty sure they're all in 0.133.0.

[kevinsawicki]

Yup, they are all in the latest release

[kevinsawicki]

Moving this back to on-deck since nothing specific to this issue is being worked on this week.

[tjfwalker]

Startup-time is my biggest and only serious gripe with Atom. All improvements are much appreciated.

[backspaces]

You may want to look at fast.js. Many parts of coffeescript use push where direct assignment is faster when the array size is known. In array comprehensions without an "if" conditional, the final array is known and should fast.js techniques.

[kevinsawicki]

@backspaces Thanks for the tip, looking into fast.js

[picibucor]

Check this out: #4293

[tomByrer]

If you like fast.js style of overriding built-in functions, try Lo-Dash. Modern build is faster sometimes. The beta/preview has lazy evaluation which may also help.

[bthusby]

Hope speed will come soon :)

[m1ga]

👍 me too! The main problem I have at the moment: I start atom (which takes a bit) and then select my old project to open (which takes a while because in linux it opens a second window). After the window is open the speed is fine. Just the "opening" time could be better

[hyiltiz]

I hate the fact that I have to wait seconds for my editor to open a file; all I do is editing.

[batjko]

How is everyone's impression these days, both compared to a few months ago and to other similar editors?

Personally, I find massive improvements in startup time since, say, version 150 or even 160. It's not quite on the level of Notepad++ (yet), but it's certainly not enough time to get a coffee anymore. I'd say roughly on par with many equivalent full-featured editors.

[mark-hahn]

When I started using atom 9 months ago I was getting 6 to 8 second loads.
When the big fix was made it went down to 2 to 3 seconds. Unfortunately I
have added so many packages it has gone back to 6 or 7 seconds. I suspect
that I can remove half of the packages. That might get it back down.

On Thu, Jan 22, 2015 at 11:50 AM, batjko notifications@github.com wrote:

How is everyone's impression these days, both compared to a few months ago
and to other similar editors?

Personally, I find massive improvements in startup time since, say,
version 150 or even 160. It's not quite on the level of Notepad++ (yet),
but it's certainly not enough time to get a coffee anymore. I'd say roughly
on par with many equivalent full-featured editors.

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

[ilanbiala]

I've noticed that it still runs slower than Sublime/N++ or other native editors, and it cannot handle more startup packages like a native editor can..

[Globegitter]

Yep same here - really like Atom Text editor, but the only thing so far noticeably worse compared to Sublime is performance. Especially startup time, having roughly the same amount of plugins. Hope there is still some room for improvements.

[charleswhchan]

On my PC:

• Notepad++ starts up <1s
• Atom v0.181.0 starts up ~3-5s (clean install)

Noticeably improvement! Keep up the good work.

[asantos3]

Hopefully someone can enlighten me or tell me if they have or not the same problem.

I'm running Ubuntu 14.04. I start the PC and then start atom, it takes about ~12s to startup but then if I close it and start it again it takes about ~3s. I also have Windows in it and the startup is about ~40s and then the startup time is about the same. Is there a better way to debug this instead of just viewing timecop?

Is this normal or what? I don't see any running processes related to atom after I close it so I doubt it's do to being in memory.

[50Wliu]

I believe it's because Atom has to load everything from fresh the first time. Every startup after that, some of those things are cached and therefore it takes much less time to load.

[batjko]

Yes, this has been observed on Windows ever since Window support came out. I wasn't aware it affects Linux as well, but there you go.

Having said that, since Windows got the squirrel updater, people don't normally have to re-install from scratch, so this issue should affect most Windows users only once.

Time for Linux to get an updater as well.

[m1ga]

@asantos3 have a look at iotop:
#5566
I have 4 apps running the first time

[asantos3]

@m1ga just tested it, doesn't happen with me. Have you tried other distros?

[m1ga]

@asantos3 no sorry. It only happens at the first start in a KDE session. So if it was open before it won't show up again. But it might get fixed with asar. So I'll wait

[asantos3]

Just cleared up my buffer cache and the startup took about the same time as the first run. As @m1ga said, hopefully this is fixed with asar. Keep up the good work 👍

[jeffmcneill]

I use multiple Atom windows with multiple tabs in each window instance. I launch these from scripts. I'm on OSX 10.10 Macbook Air 2011 with 4gb RAM. It takes about 4 seconds to launch each window (after the first instance each window launches an Atom Helper process with about 100mb ram).

Is there any way I can get that 4 second launch time down to 1-2 seconds?

[50Wliu]

There will be some speed improvements arriving in 0.193.0. You can also try starting Atom with the --one argument if you don't have any packages that rely on deprecated APIs. For most people that speeds up loading time by 200-500ms.

[jeffmcneill]

@50Wliu Thanks I do see some improvement with the -1 and on 0.194.0. Still some more speed would be nice, but there is progress here.

[benogle]

@jeffmcneill is atom --safe any faster? You may have packages slowing things down. Looking at timecop (cmd-shift-p, search for timecop) will show you which ones are the biggest offenders.

[yongkangchen]

I suggest that atom should have package load level instead of load all package at start time.
For example:

• tabs、status-bar、tree-view are the level 1, which load and active on start.
• other packages are level 2, which should delay load and active when atom started.

see #4293

[mark-hahn]

instead of load all package at start time

What if a level 2 package modifies the appearance of a level 1? Then you
would see a "pop".

On Tue, Apr 28, 2015 at 11:03 PM, Yongkang Chen notifications@github.com
wrote:

I suggest that atom should have package load level instead of load all
package at start time.
For example:

• tabs、status-bar、tree-view are the level 1, which load and active on
  start.
• other packages are level 2, which should delay load and active when
  atom started.

see #4293 #4293

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

[jeffmcneill]

I've disabled several core packages, including markdown preview, and things have sped up. See attached for my Timecop on one of the instances (with 5 tabs, about 14,000 words that the wordcount needed to count.

It's not instantaneous but definitely better. I use atom to write books with (previously used Multimarkdown and others). Each chapter is a markdown+latex file. With notes and other items, about 30 text files are in a directory (only about 7 might load into tabs).

@benogle --safe is faster, but I can't tell exactly because Timecop doesn't load. My process also adds a little overhead as I am double-clicking on .sh scripts to launch a Terminal that then executes change directory and invoking Atom.

Total load time is in the 3-4 second range (using a stopwatch). It does feel faster now. A 2 second load would be nice to have at some point. The tuning with turing off packages and using -1 and the latest version is definitely an improvement.

Latest Timecop:

[yongkangchen]

Just for a example. Package should can define the level in package.json, so
package which modifies the appearance should be defined level 1.

2015-04-29 14:13 GMT+08:00 mark-hahn notifications@github.com:

instead of load all package at start time

What if a level 2 package modifies the appearance of a level 1? Then you
would see a "pop".

On Tue, Apr 28, 2015 at 11:03 PM, Yongkang Chen notifications@github.com
wrote:

I suggest that atom should have package load level instead of load all
package at start time.
For example:

• tabs、status-bar、tree-view are the level 1, which load and active on
  start.
• other packages are level 2, which should delay load and active when
  atom started.

see #4293 #4293

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

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

[ypresto]

I created PR for improvement here!
atom/deprecation-cop#54

[Penagwin]

Do plugins load asynchronously? Can they even load asynchronously? Would that help load times at all?

[jpxd]

Async package loading would be really great!
On some packages I try to cheat at the activation time by adding a timeout and executing the activation code 5 seconds later to shorten the time until I see the editor window. I would love If one could specify when the package has to be loaded and activated in the package.json in cases where activationCommands are not an option.

E.g.
sync loading before editor is shown or
async loading in the background after the editor is ready and already shown to the user.

[josevimlet]

As a quick fix atom editor should have a background service like chrome does, this a simple solution that should work even with lots of packages and improve the experience on non SSD owners. Service mode could have an enable/disable option for people who might be short on RAM, but now days a small service running in the background shouldn't be an issue for any hardware. This doesn't mean startup improvement efforts should be halted, nevertheless atom as a service should be a option no matter the startup time.

I think atom is awesome, and js (and friends) as the GUI is a perfect choice, with all the promised "hackability" and beauty only achievable by a cornucopia of options, but IMO most user, including me will be drawback by the current startup speed ~4s.

A text editor, no matter how many cool things it has, will fail as a text editor if startup time is >1s simply because the experience is not acceptable compared to other native apps, this fact won't pass unnoticed to most people, but once again its just my constructive opinion.

[benogle]

IMO most user, including me will be drawback by the current startup speed ~4s.

Note that there are a few huge speedups coming up in the next couple versions of atom:

• Huge speedup from a native compile cache #9318 (in master)
• Unfold all 🐎 #9468 (in master)
• Lazy snippet loading atom/snippets#182 (soon to be in master)

Startup speed is @as-cii's full time focus right now. He is finding and improving things weekly, so keep an eye out for new stuff!

[josevimlet]

Great!, looking forward to it, nice work.

[timofonic]

Is this a step forward to having a more native-like performance? Great!

[tomByrer]

When measuring speed, might want to factor in Chrome's garbage collection services.

[ilanbiala]

@benogle any update on this?

[passeride]

Suggestion: i have disabled some packages for faster startup, now if i could toggle them from the Shift+Ctrl P menu, that would be a great addition for me (But not as default tho), also would it be possible for a deamon to keep it running in background?

[Tzrlk]

Any thoughts on incorporating something like #4293 to get the editor displaying faster up-front? Or adding an option on the plugins to delay their startup?

Additionally, have you thought about using something like http://rollupjs.org/ for tree-shaking? Certainly running a tree-shake, minify and bundle as a runtime cache per combination of plugins should get subsequent load times up a bit?

[50Wliu]

We are actively working on this in #13949, #13940, #13916, and other PRs.