Atom: Editor window startup is slow

[renatodex]

Hi, i have used Textmate for a loong long time. But also as a big fan of new things, i decided to try Atom for curiosity purposes.

It turns out that i found Atom a great platform for day-by-day development, and im using it Atom now. But theres one thing annoying me:

I usually open Atom using the Shell command "atom [filename]", and compared to "mate [filename]" (the same command Textmate use for open files using Shell), Atom is incredible slow (i feel i have to wait twice of the time, like 1s~2s).
I know this performance also is related to machine specs, processors, memory and etc. But its the exactly same task executed for different tools.

I can record a video showing that behavior if you like.
Also, if this is a un-prioritize known issue, i can submit a pull request if theres noone working on it. I just need to know where to start looking.

][`s

[benogle]

This is important to us, but we're not actively working on it right this second as we are focused on the react editor and windows support.

Definitely look into this if you feel inclined. I would start with profiling, and the timeline.

[renatodex]

Great,
Where i can learn more about the project structure?
Should i dig into the code or there is some explanatory guide for starter contributors?

[benogle]

Before you start digging into this, you might be able to speed it up by disabling some packages.

• Open time cop (cmd-shift-p search for time cop)
• Or open atom --safe which opens with only core packages enabled

Probably digging into the code would be easiest. If it were me, I would profile first, then for the slowest parts, dig around in that code and see what is going on.

To create a profile for startup in https://github.com/atom/atom/blob/master/src/window-bootstrap.coffee you can programmatically start and end a profile:

console.profile('Startup Time')
...
console.profileEnd('Startup Time')

[benogle]

So add those lines, and open a dev window (atom -d in a code directory). Profile a couple different editor states, eg.

• nothing open
• a couple long files open
• a split pane
• non-git dir / git dir
• etc

[renatodex]

Thanks Ben, i appreciate your help!

[benogle]

Also, this is probably death by 1000 paper cuts. There will be no one thing that is a huge slowdown. With no files open and no treeview open, it opens in 500ms for me. With one medium size file and the tree view open, it takes ~1 second. There are 100 things involved with that extra 500ms. Reading the directory, Treeview rendering, reading the file, tokenizing, buffer rendering, etc. Each of those things might have small things to speedup.

If you want to start small, the slowest builtin packages to load / activate are markdown preview and the treeview (they take a total of 150ms on my machine). Maybe there are things to speedup there?

[renatodex]

Yeah, im looking into that right now. There are 67 core packages loading here. With atom --safe, 223ms was spent on packages loading (67 packages), and 262ms was spent on package activation (60 packages). At all, 485ms was spend on package loading and activation.

I think the key point here is delay some packages to load after start. Because sometimes, the first essential is only content, identation and menu. Treeview, bracket matcher, markdown-preview, and even status bar are not theorically essential to see the raw contents of a given text file.

Bottomline i agree with you, its death by 1000 paper cuts. But also, i think its a matter of loading things when they are really required. For instance, when you type "atom .", you are probably looking first for the whole structure of a given folder. But when you type "atom myfile.txt", you are probably looking first for the content of this file, so you probably wont worry about not having the Treeview on the first second. And its just that we are talking about, a single second.

I dont know if its reasonable, what do you think?

][`s

[benogle]

Async loading of the packages has been talked about a lot in the past. There are some strong opinions about it. I can see the non-essential packages being loaded async. I'll try to dig up some of those old discussions tomorrow.

[lee-dohm]

One thing that I've done with a few of my packages (even the small ones) is I've lazy-loaded everything possible. Like with my tabs-to-spaces package I create commands that first load the code and then executes it:

TabsToSpaces = null
tabsToSpaces = null

module.exports =
  activate: ->
    atom.workspaceView.command 'tabs-to-spaces:tabify', ->
      loadModule()
      tabsToSpaces.tabify()

# ... snip ...

# Internal: Loads the module on-demand.
loadModule = ->
  TabsToSpaces ?= require './tabs-to-spaces'
  tabsToSpaces ?= new TabsToSpaces()

I've generally found that this kind of lazy-loaded package is faster (at least for initial startup) than using activationEvents from the Timecop view's perspective.

[countergram]

I just decided to try Atom on OS 10.8 on an (older) Macbook Pro and it is very slow. Opening a new window particularly. Timecop also drastically under-reports total window load time from the user perspective, and the sub-categories' times do not remotely add up to the total time, so I'm not sure where all the extra is coming from.

E.g.: timecop usually shows a "window load time" of between 1500ms and 3000ms, although there was one 10000ms that I haven't been able to repeat so far. It seems highly variable. But my stopwatch (from the moment I run atom --safe from the command line) generally reads 4-8 seconds. This is with Atom running in the Dock so app startup is not included.

For comparison running subl (or subl . which loads a files view) with Sublime Text 2 running in the Dock is practically instant. I cannot manually time it.

When I have time I'll try the profiler code you mentioned.

[kevinsawicki]

@countergram The window load time is the time for that render process to load, there is a parent process that also loads when the app launches and creates the window> I'll add that time separately in TimeCop so they can be differentiated, thanks for mentioning this.

[batjko]

I think this issue also adds to the perception that Atom is not good enough to be used as a full-fledged IDE. The fact that it isn't supposed to be, doesn't matter to those arguing this point.

It's the difference between, say, Eclipse and Notepad++:

If I know I'm opening an IDE with tons of complex features etc, I anticipate the launch to be a chance to go and get a coffee and I'm fine with it. I expect that I'll be spending the rest of the day in a project, with various screens, plugins, hours-long sessions at a time etc... it's a platform.

But If I expect to open a text editor to quickly look at the content of a single source file, I expect to see this near instantly and probably intent to close it again shortly afterward.

It's a bit hyperbole, but those are essentially the two mindsets from which Atom is being evaluated.
And at the moment it's stuck in the middle between the two.

If it's a text editor, Atom's long launch time is hard to understand compared to other rich text editors (e.g. Notepad++ again which is practically instant despite being full featured).
If it's an IDE, so far it lacks a lot of those heavy features usually expected of them based on Eclipse, IntelliJ etc.

Does Atom need to choose sides? Maybe.
But maybe it can soon be flexible enough to accommodate both expectations, and I think speed is going to be the major factor for those wanting to use it as a text editor.

Just thinking out loud here...

[starquake]

Great point batjko. The thing Atom reminds me off is Sublime Edit. Which is very fast. It also wouldn't bother me if the first startup would show a splashscreen for a second. But what I think is a letdown is that opening a new window takes so much time. Or should I view the new window as a new instance of the application?

Anyway, a splash screen might help.

Also just thinking out loud...

[countergram]

A splash screen would only really "work" against application startup time. The issue here is that even when the app is started, opening a new window is slow.

I did get it to build eventually and ran the profiler. I didn't see any "quick wins" in terms of contributing. What stuck out at me is how pretty much everything is being done per-window - dynamically loading modules, parsing and eval-ing different kinds of code & config, etc. Is this a design decision or a limitation of Chrome? Because the first thing I would say is centralize & share modules and config, but if that's not even possible because it's Chrome the I don't know what to say.

[kevinsawicki]

Is this a design decision or a limitation of Chrome?

Each window runs in its own "render" process meaning nothing is shared between them and they communicate by talking over IPC to the main "browser" process that starts when the app launches.

[rsanchezsaez]

I can't contribute much other than giving my _+1_ to whoever tries to fix this _issue_. I really want to like Atom, but it's slowness (specially compared to TextMate 1.x) is killing me.

[countergram]

Would chrome let you compile/parse things in the browser process and pass the resulting objects out over IPC to windows? You'd still have some per-window "load" time but it looks like a bunch of compile/eval/parse related operations make up a big chunk of time in the profiler.

[xpol]

(Tried on Windows)

The current version 0.120.0 is still too much slow.

It's no match for Sublime Text 3.

Can we catch up with Sublime Text 3?

[renatodex]

Totally agree with batjko.

Theres a whole world of difference between these 2 mindsets.
I couldnt see these 2 scenarios when i first started the issue, but now, something comes to my mind:

First hour in the morning i open my Macbook, open Shell, cd to my project folder and _instantly_ run "atom ." from terminal. The loading time really does not bothers me at all for the first time, since i will keep the window opened for the rest of the day.("bothering level" = 0) But happens that actually i working simultaneously with 3 projects (backend, frontend and api), so i have to open 3 atom windows. At this time, my "bothering level" is 1.

As i use git with all those 3 projects, sometimes i am operating the shell, commiting, creating branches, pushing or etc, and i figure out that i have to quick look at the content of some specific file, and i think: "It would be faster if i run 'atom filename' from here than figure out which one of 3 atom windows is the current project, press cmd+t and type the filename and hit enter"
But running 'atom filename' command from terminal finally raise my "bothering level" to 2!

This happens because for quick look cases, the atom loading time underperforms the sequence of actions to get the opened window, press cmd+t, type the filename and hit enter.

I dont think Atom is a slow editor. By the opposite! I think the loading time is great for what he do and how he do. But i would love if there was a smart way for the command line tools detect if you want open a set of files, or a single file, and create a flexible quick mode for those who want to see a single file without having to load a bunch of packages that are not going to be used.

Its not an issue related strict to the command line tools, but how Atom should deal with those different mindsets.

By the way, i really appreciate the work on Atom, its simply fantastic!

[Zren]

Opening a file in the active window should give the appearance of speed. #1722

[odensc]

Just saying, Atom takes ~12 seconds to open an editor window on my machine. Sublime Text, in comparison, takes ~2 seconds.

[tosh]

Also just wanted to chime in and add a +1 here.

The current startup time compared to other editors makes Atom come across as very heavyweight whereas the app itself (once started) feels slick and lightweight. This feels weird re UX.

If you're in the terminal and just want to quickly open and edit a file using atom filename really is a flow/thought/workflow/productivity interruption.

[ceyhunkerti]

Don't want to be annoying but;
i have reported similar issue about 3 months before, when i was already having the issue for quite some time. I have been following the builds constantly but it does not seem to get any acceptably faster. In some distant feature probably i'll try atom again but for now, it is far from being productive and/or usable because of the speed issue.

[karolszk]

Indeed, I've just installed v0.125.0 of atom and is slow (windows). Pressing a single keyboard character shows how slow is char rendered.

[Giancarlos]

How about priority based plugin loading? Some plugins HAVE to be loaded on startup, others could be loaded sometime after, and then there's a whole group of plugins that are only ever used when you run a command such as the Markdown Previewer. Why not have priority based loading of plugins? If a command takes an extra second the first time I think people wont mind, they'll just assume Atom is thinking really hard. Just my two cents. There's a lot of plugins I disabled that I don't use right away, just to speed up load time. I can manually enable them after Atom loads, or... it could be automated?

[ddlsmurf]

Is it possible to pre-load a render process with the configuration, then fork that for new windows ?

[muchweb]

Some plugins HAVE to be loaded on startup, others could be loaded sometime after, and then there's a whole group of plugins that are only ever used when you run a command such as the Markdown Previewer.

@Giancarlos, this is already in place and is the way how package 'activation' works. It is up to indvidual package devepoper to specify, when package should 'load'. The recommended way is, as you have mentioned, on-demand, when it's action is called by a user, as in 'Markdown Previewer', for instance.

[kirualex]

I often end up with 3 instances open as I click multiple times to open Atom. It's really frustrating and for now one of the only reason left I'm still sticking with Sublime.

[tmikaeld]

This gives me an eerie feeling similar to when i use Grunt for processing files.

[starquake]

Not sure which Atom version and OS I was using when I joined this discussion but I must say performance of Atom v0.133.0 on Mac OS X is acceptable. Though it might be the hardware (I7 with SSD). It fires up in about a second.

[muchweb]

@starquake, I confirm, it does opens really fast on a fast machine (i7, SDD). But so does everything else :smile:.

It should be well-optimised everywhere. Also opening large files or many small files, syntax highlighting seems to be real performance bottleneck.

[YafahEdelman]

I'm on ubuntu and it takes several seconds for me too. I thought it was a Ubuntu only problem when I had it. Its a bit annoying that at times I resort to Gedit rather than wait the few seconds for atom to load on a small file.

[necaris]

Would it be possible for Atom to check if a process is running and, if so, open the file in that process (I'm thinking like Emacs in server mode)? I don't know how well this would mesh with people's usage of Atom but it would certainly solve the quick-look case...

[SchizoDuckie]

Am I wrong to think it's a matter of opening hundreds/thousands of files during the startup process? (seeing people using ssds have blazing speed, and startup speed is not only slow on windows)

Wouldn't it help to minify/concat plugins after installing them so that you just have one big file per bunch of plugins?

If you open thousands of files, you're basically raping your harddrive's read head. Even with async loading you still only just spread the problem a bit. Depending on drive fragmentation, you can be in a load of pain.

[martinheidegger]

@SchizoDuckie Solid reasoning :+1:

[muchweb]

@SchizoDuckie, yeah, NPM is well-known for raping hard drives :smiley:

[skrat]

~1s startup for such a complex thing is not that bad actually. +1 for lazy loading packages, +1 for loading them async. those are all good ideas, and not too hard to implement IMO (once you get the dependency tree out of the way). One thing I don't get about this issue is: your use case of opening files/dirs from command line using atom command, shouldn't result in a completely new process every time, and you shouldn't be killing the editor because you're done with one file. It should run a background process with all the resources/packages loaded, and when you issue an atom blah.js command, it should just tell the running process to open it. eg. the way Chrome does it, there's even some term for it, but sorry, I can't recall it.

[starquake]

@countergram says "The issue here is that even when the app is started, opening a new window is slow."

But as far as I know files should still be in the cache so the bottleneck should not be the harddrive right?

[SchizoDuckie]

@starquake that sounds like an assumption on the level of garbage collection that webkit does, I wouldn't bet any money on it.

[SchizoDuckie]

Anyway, all of this can easily be traced, either on linux with sysdig or on
windows with one of the sysinternals tools. I'd say let's see some loading
patterns first.

On Wed, Oct 1, 2014 at 4:00 PM, Jan Visser [email protected] wrote:

@countergram https://github.com/countergram says "The issue here is
that even when the app is started, opening a new window is slow."

But as far as I know files should still be in the cache so the bottleneck
should not be the harddrive right?

—
Reply to this email directly or view it on GitHub
https://github.com/atom/atom/issues/2654#issuecomment-57467978.

[Zren]

Technically. running atom in the console will launch a new process no matter what, it just completes very fast by noticing the other process using a semaphore/mutex, and communicates to it. Atom currently does this.

Opening a New Window from the File menu.

Atom will not open a new window if atom currently has a window open when the project root folder is the same as the opening file.

[tobyl]

From a purely non-technical perspective, I used Sublime Text for a long time and never had an issue with speed. I use Atom now, and speed is one of the biggest pain points. Comparing with an IDE seems excessive, but comparing with Sublime Text (for my needs) seems fair.

That said, Atom has some great features and development seems to be progressing at lightning pace. I guess I figured it's a trade-off for using beta/pre-beta software.

[alanhamlett]

Here's an example of a 180ms time savings when loading a package: wakatime/atom-wakatime#1

Loading dependencies in the global scope added 180ms to Atom's startup time. After moving all requires into the package's activate method Atom's startup time went back to normal saving about 180ms:
wakatime/atom-wakatime@879e1ff89c360658af2d8206ededfd65eb7e727c

Just one package doing this was noticable, image If you install a few packages that load dependencies in the global scope...

[swang]

Well, according to that diff you also dropped jQuery. So how do you know the savings isn't from that?

[alanhamlett]

Yea, I tested with jQuery in the activate method to make sure it wasn't a special case involving jQuery.

I also loaded multiple dependencies in the global scope and they all slowed down Atom's startup time about the same amount so it wasn't the dependency being loaded. It was the act of loading any dependency outside the activate method which slowed down Atom.

[anandthakker]

@alanhamlett I'm puzzled about this -- was thinking about package lifecycle (module loading and activation) in another context and found that a package's main module isn't actually loaded until activation.

E.g.: with the module in this gist, the log statement doesn't appear when you load Atom, but rather when you activate the package.

[thedaniel]

Am I wrong to think it's a matter of opening hundreds/thousands of files during the startup process? (seeing people using ssds have blazing speed, and startup speed is not only slow on windows)

This is plausible, in fact we've talked about both deduping npm dependencies across packages as well as concatenating atom js in the release build as a way to reduce startup time. I know there's at least an issue or PR going for the first item, but I can't find it at the moment.

[kevinsawicki]

I am working on implementing a module cache in ~/.atom/packages/node_modules for packages to share, https://github.com/atom/apm/pull/200

[kevinsawicki]

The plan is to initially add a dedupe-package-modules command, have people give it a spin, and then eventually run it as part of apm install to pull up common dependencies which should speed up require time for packages that use a common set of modules: fs-plus, pathwatcher, request, etc.

[SchizoDuckie]

Sounds like an excellent start. Any ideas on if concatting the js after an install into a one-file package for all your plugins would cause any problems? I can imagine there's a huge performance increase when introducing a sort of 'production mode' and grunt + @kevinsawicki's cache (sh/c)ould make that easy as pie

[thedaniel]

IMO the key with doing something like concatting / minifying is to preserve useful debug information, a la source maps. Pretty bad/annoying to debug and have the error traced back to line 5, position 36,001 of some processed file. Fortunately tooling already exists for this kind of thing.

[kevinsawicki]

Any ideas on if concatting the js after an install into a one-file package for all your plugins would cause any problems?

Yup, we've experimented with this on a couple branches for the packages bundled with Atom with notable improvements.

There were a few remaining issues such as keeping source maps working to ensure stack traces are still helpful.

Also there was an issue of deferred requires, often packages use a large library such as d3 in one very specific case, like clicking a button to show a graph of something.

Ideally they would not require d3 until that button is clicked, and at that point the 50-100ms require time wouldn't be noticeable compared to paying that on every startup.

But if apm install concatenated all their files then d3 would be loaded at startup and potentially slow down startup even when the package author was doing the right thing and deferring the require.

[karolszk]

Hello All,

Let's try to use very simple and powerful profiler: http://www.codersnotes.com/sleepy to check what causes such poor atom performance. Regards, KarolSzk.

[blixt]

How much memory/idle CPU does a new window use if it's just idling? Would it be infeasible to prime Atom with a ready-to-go (but invisible) window at all times, so that the next open command can show it instantly? It would definitely be easier than lazy loading code (which requires a lot of logical separation of dependencies, not to mention it potentially comes with an overhead of its own).

[SchizoDuckie]

@kevinsawicki a very simple fix for the large libraries would be to set an arbitrary filesize limit limit for autoloading and auto-concatting files. js files exceeding that limit could still be async-loaded with regular requirejs calls perhaps. Good to hear that it's a work in progress!

[ajmath]

FWIW It takes me around 2.8 seconds to open a small file on an i7 SSD MBP. This is with an existing instance of Atom running.

EDIT: After updating to the latest version this jumped down significantly. This was also me manually timing with my phone.

[benogle]

@matheeeny can you post a screenshot of your timecop view?

[ajmath]

@benogle

After making the comment above I updated atom to the latest version and experienced significantly improved times. I have edited the comment to include this.

Here is the screenshot nonetheless:
https://dl.dropboxusercontent.com/u/424533/Screen%20Shot%202014-10-01%20at%203.58.08%20PM.png

[benogle]

Thanks for the screenshot.

@kevinsawicki has been and is currently working on this. Progress: https://github.com/atom/atom/issues/3673 There is certainly more work to be done, but I want to be clear that it is important to us.

[DavidLGoldberg]

Anyone look at vulcanize for the concat? It might help with the source maps (not sure).

I also had an idea similar to what @blixt was saying. Maybe a pool of windows, reminds me almost of the row virtualization issue...

I know any of the above is a lot of work :-) I know it's also almost definitely death by 1000 cuts, that said, I think there are probably a few big wins..

[sergiotapia]

Still extremely slow for me. Sublime Text 2 open cold in less than a second, Atom takes around 7 seconds.

[thedaniel]

@sergiotapia wow, 7 seconds is pretty brutal. Hopefully this will improve in the next release, but just to satiate my curiosity - what version and platform are you on, and can you attach a screenshot of your timecop output? (Open the command palette and run Timecop: View)

[odensc]

I can't really use Atom anymore, yikes...

[thedaniel]

@thesbros can you post your platform, version timecop view as well?

[odensc]

@thedaniel:
OS X Yosemite 10.10 (14A388a)
Atom 0.137.0
Seems to be a bit better now.. But still pretty bad.

[benogle]

@thesbros do you have an SSD or a spinning HD?

[odensc]

@benogle Mechanical / Spinning.

[benogle]

138 should come out today and be much faster. Will comment when it's out.

[benogle]

138 is out. Please update and report back with new load times.

[thedaniel]

Also it should help to run apm rebuild-module-cache after updating.

[thomasjo]

Not sure if this is generally necessary (or even advisable), but after upgrading to Atom 0.138.0, I shaved off almost 400 ms startup time by nuking my storage folder (rm -rf ~/.atom/storage) and then doing apm rebuild-module-cache.

[kevinsawicki]

@thomasjo Interesting, reading the storage shouldn't be slow, but if packages are writing tons of data there it could make those files large and take long to parse.

I'll add the storage read time to timecop to help diagnose this.

[odensc]

After updating to 0.138.0, deleting ~/.atom/storage, and rebuilding module cache I'm at 2 seconds load time. That's a huge improvement.

[thomasjo]

@kevinsawicki I noticed the speedup accidentally. Reason for nuking the storage was a missing _Packages_ menu and empty _Find_ menu. Just happened to notice the massive improvement in load time for that particular project.

[thomasjo]

@thesbros Nice! :+1:

[tobyl]

great improvement for me.. thanks! (Yosemite, Late 2009 iMac, 3.06Ghz C2D, 16GB RAM)

[mark-hahn]

My load time went from around 7 secs to 2.7 secs. BTW, the load time was
the same before and after running apm rebuild-module-cache.

On Fri, Oct 17, 2014 at 1:49 PM, Thomas Johansen [email protected]
wrote:

@thesbros https://github.com/thesbros Nice! [image: :+1:]

—
Reply to this email directly or view it on GitHub
https://github.com/atom/atom/issues/2654#issuecomment-59574018.

[martinheidegger]

@benogle The update seems pretty smooth but still recognisably slower than Sublime Text. Before I would consider that request solved I feel that Atom has to hit the < 1second mark.

[thedaniel]

Before I would consider that request solved I feel that Atom has to hit the < 1second mark.

I agree with the sentiment that we should set a goal, but the measurement is so fraught with variables that just picking a time doesn't quite work. For example, on my machine with no packages, I'm already nearly there. It would be nice if we had a reference configuration at least if we're gonna set benchmark goals (e.g. < 1s with no other programs running on a machine with x y z disk and ram, etc)

[50Wliu]

Before:

After:

After, with deleted storage and apm rebuild-module-cache:

All of these are after I started Atom once, closed it, then started it again.
Strangely, Atom seems to be taking longer to load after starting it up once and then closing it...(I was at ~1500ms).

[benogle]

@martinheidegger On my machine it _is_ 700ms :p.

This will get better. We (kevin) have several more ideas, and it's an initiative for 1.0.

[mark-hahn]

Did I understand correctly that the package.json files are supposed to have something added to them by apm rebuild-module-cache? I just looked at one and it was untouched.

[kevinsawicki]

@mark-hahn They are, a _atomModuleCache field

Linked packages aren't affected though.

[mark-hahn]

Linked packages aren't affected though.

Aha. Why is that? I have a dozen or more linked packages.

On Fri, Oct 17, 2014 at 2:54 PM, Kevin Sawicki [email protected]
wrote:

@mark-hahn https://github.com/mark-hahn They are, a _atomModuleCache
field

Linked packages aren't affected though.

—
Reply to this email directly or view it on GitHub
https://github.com/atom/atom/issues/2654#issuecomment-59581611.

[kevinsawicki]

Why is that? I have a dozen or more linked packages.

Because linked packages usually suggest that those packages are in cloned repositories and writing to the package.json file would make it dirty and display when running git status,

The cache information should be computed at install time, not checked in as a change to the package.json file.

[sergiotapia]

Just want to thank you guys for your time, Atom can only get better! :)

[mark-hahn]

Because linked packages usually suggest that those packages are in cloned
repositories

Hmm. I also have cloned packages in ~/atom/packages. I think maybe the
whole idea of storing state information in such an important file is
fundamentally flawed.

On Fri, Oct 17, 2014 at 4:17 PM, Sergio Tapia Gutierrez <
[email protected]> wrote:

Just want to thank you guys for your time, Atom can only get better! :)

—
Reply to this email directly or view it on GitHub.

[martinheidegger]

@benogle @thedaniel I would assume the most common dev computer from two years past in a reasonably low configuration. I'd assume the mid2011 MacBook Air 11" http://support.apple.com/kb/SP631 running atom with the 15 (or average plugin amount) of most popular plugins. (I don't know if you have those stats)

[RaginBajin]

I am on a MacBook Pro mid-2011 running on mechanical disk. I've done the apm rebuild-module-cache as well as updated to the latest release. I am still seeing issues. The time I tried before what you see above it took over 21000 ms to open. It's getting a little crazy.

[nuivall]

Also timecop doesn't show the whole load time, right? Chromium has to load first.

[kevinsawicki]

Also timecop doesn't show the whole load time, does it? Chromium have to load first.

Timecop shows the load time from when the window onload event fires to the time the window finishes loading and is displayed initially, this includes all the time taken to reopen tabs, and load themes, packages, keymaps, and menus.

Timecop also shows the load time from when the app launches to when the first window is created, this includes all the time taken to parse command line arguments, setup the crash reporter, and create and configure a native window.

[lee-dohm]

@kevinsawicki So, the majority of the stuff that the Atom team has control over without submitting a patch to the Chromium project?

[kevinsawicki]

So, the majority of the stuff that the Atom team has control over without submitting a patch to the Chromium project?

Pretty much, we've never really profiled Atom shell load time deeply and seen about possible optimizations there, but that would probably be a max speedup of 100ms since the Shell load time is usually never the bad one, the Window load time is and Atom is in complete control over that.

[nuivall]

I didn't look deep into Atom architecture ( nice detailed diagram would be
welcomed :) ) but it is reasonable to say that the second window shouldn't
load as long as the first one. Couldn't packages and other stuff be shared
across all windows?

An option to stay in tray might be useful, especially to people who use
Atom as a secondary editor, along with some heavy IDE.

2014-10-21 2:21 GMT+02:00 Kevin Sawicki [email protected]:

So, the majority of the stuff that the Atom team has control over without
submitting a patch to the Chromium project?

Pretty much, we've never really profiled Atom shell load time deeply and
seen about possible optimizations there, but that would probably be a max
speedup of 100ms since the Shell load time is usually never the bad one,
the Window load time is and Atom is in complete control over that.

—
Reply to this email directly or view it on GitHub
https://github.com/atom/atom/issues/2654#issuecomment-59861262.

[kevinsawicki]

Couldn't packages and other stuff be shared across all windows?

Perhaps, but each window runs in a separate render process so shared information would have to be sent over ipc and would have to be serializable.

This is something we can definitely look into for certain state that is quicker to send over than to re-read off disk, but I'm not sure what gains could be expected here.

[nuivall]

separate render process

I would rather worry about v8 stuff, which might be difficult to hack, than IPC. Chrome for instance runs all pages from the same domain in the common renderer process (JavaScript sharing might be beneficial so maybe they have it).

[Zren]

Also timecop doesn't show the whole load time, right? Chromium has to load first.

Edit: These times are wrong. It's actually 100-200ms. See here.

Fair warning, this profiling is from v123 (which doesn't include the v138 speedups). It's also done on windows, and not sure what NodeJS version.

There's approximately 600ms (Edit: Misleading, $( date +%s ) is not accurate) before the start of shellLoadTime in src/browser/main. I measured this with

export ATOM_LAUNCH_TIME=$( date +%s )
"C:\Chocolatey\lib\Atom.0.123.0\tools\Atom\atom.exe"

[lee-dohm]

@Zren Wouldn't much of that 600ms you cite be the time it takes the OS to:

1. Parse the command line
2. Read the executable from disk
3. Create the process
4. Branch to the entry point of the executable

None of which Atom has any control over?

[nuivall]

I would say especially point 2. But also initialize chromiumlibcontent
which probably takes most of those 600 ms. And I agree little can be done
there, but whole time should be taken into account when comparing to other
programs.

2014-10-21 10:51 GMT+02:00 Lee Dohm [email protected]:

@Zren https://github.com/Zren Wouldn't much of that 600ms you cite be
the time it takes the OS to:

1. Parse the command line
2. Read the executable from disk
3. Create the process
4. Branch to the entry point of the executable

None of which Atom has any control over?

—
Reply to this email directly or view it on GitHub
https://github.com/atom/atom/issues/2654#issuecomment-59897356.

[muchweb]

1. Parse the command line
2. Read the executable from disk
3. Create the process
4. Branch to the entry point of the executable

@lee-dohm, these are such minor essential OS operations that would only take a fraction of millisecond. It's the weblit, a monstrous engine that takes majority of time, as @nuivall has pointed out.

---

I am wondering if Atom is creating separate chromium for every window, and, if so, would it be possible to treat Atom windows as "tabs" of one, shared, "web browser" (that could be running as a separate backgound process). This could eliminate overhead of running several webkits and make Atom windows open as fast as new tab in a browser (probably) :smiley:

[gespinha]

Is it possible that a decent optimisation brings Atom's startup time to something comparable with Sublime Text 3?

[Zren]

I've redone my tests, turns out it's not that bad. Appears I was doing atomLaunchTime * 1000 to get it in milliseconds. >.<' Also found out that the output of $( date +%s ) can be after shellStartTime, so that's horribly inaccurate.

I found out about process.uptime() in the process however.

Number of seconds Node has been running.

Milliseconds are shown as it's a real number.

global.shellStartTime = Date.now();

if (process.env.ATOM_LAUNCH_TIME) {
  global.atomLaunchTime = parseInt(process.env.ATOM_LAUNCH_TIME, 10);
  console.log('process.env.ATOM_LAUNCH_TIME', global.atomLaunchTime, 'sec');
}
console.log('shellStartTime', global.shellStartTime, 'ms');
global.shellStartUptime = process.uptime();
console.log('process.uptime() @ shellStartTime', global.shellStartUptime, 'sec');

Gives the output of:

process.env.ATOM_LAUNCH_TIME 1413906651 sec
shellStartTime 1413906651362 ms     
process.uptime() @ shellStartTime 0.118 sec
"Window load time: 1280ms"

process.env.ATOM_LAUNCH_TIME 1413906950 sec
shellStartTime 1413906949741 ms            
process.uptime() @ shellStartTime 0.122 sec
"Window load time: 1279ms"

Which means NodeJS has been running for 100-200ms beforehand. And yes, there's not much you can do about it besides knowing it's there.

[kevinsawicki]

@50Wliu I'd be curious if the changes in #3917 made a noticeable improvement for you, it was just released in 0.139.

You'll want to run the same apm rebuild-module-cache command after upgrading.

[50Wliu]

4395ms after initial startup after updating, 1392ms on the second, 2045ms on the third.
Tree View still takes the longest to activate out of all the default packages at 32ms (compare that to 2nd place, Tabs, at 9ms). I subtracted around 1.5 seconds from each one due to one of my packages taking that long to load.

Atom still takes an eternity to start the first time you do it though...74 seconds ._.

[kevinsawicki]

Atom still takes an eternity to start the first time you do it though...74 seconds ._.

The first time after an update? Or every time you launch Atom?

[50Wliu]

The first time I start it after logging in.

[TheChymera]

I'm also having issues with atom's startup time. It looks minimal enough, but over here it's 2-3 times slower to start than Geany (also, more of an IDE than a text editor!)

How can I benchmark my startup times? you keep linking timecop pics, but I can't find it. Or, rather, I can, but I can't see how to get such pictures :(

[Macsch15]

Not bad, but still slower than Sublime Text 2:

Running on 4 cores i5, windows 7 x64 and 8gb ram, ssd.

Cheers!

[thedaniel]

@TheChymera You can run Timecop from your command palette, it's packaged with Atom by default.

[TheChymera]

Ok, so over here it _says_ takes:

1692ms - window load time
389ms - shell load time
322ms - workspace load time
35ms - project load time
104ms - package loading
338ms - package activation
11ms - themes

That should make about 3s (which is quite horrid in itself) - but I can swear it actually takes even longer for it to load.

[odensc]

@TheChymera Me too. It says my window load time is around 1500ms, but it feels like it is taking at least ~2000ms more and it also bounces in the dock for around 3 seconds before it actually starts up (the indicator dot under the icon).

[TheChymera]

Ok, so I restarted my computer and here's a more realistic benchmark:

I'm not joking when I am saying that this is the slowest I have ever experienceed in a text editor. Even Eclipse (such an abomination, that) leaves atom in the dust :-/

[thedaniel]

There's something about your environment that makes it much worse than other people in this thread. What's your machine like? SSD or mechanical disk? What OS?

[thedaniel]

(Not that I'm saying it's your fault, it clearly shouldn't be doing this, but maybe we can find the weak points)

[odensc]

When I load up a project it takes around 20 seconds. A single file takes around 6 seconds.

OS X 10.10
2.5 GHz Intel Core 2 Duo
4 GB RAM
Hitachi HTS542525K9SA00 (5400 RPM)
It may be that cringey hard drive, but other editors don't take nearly as long to load up.

[TheChymera]

Dell studio XPS, sporting:
HDD
2.5GHz Core2 duo
4GB RAM
a recently updated Gentoo system

Having said that, I would be outraged at a text editor "requiring" SSD :grinning:. Though not benchmarked, Geany launches in about 2s and chromium with ~30 open tabs in about 6s.

So even if my system is somewhat slow, I see little reason for a text editor with 3 tabs to launch so much slower than a web browser with 30. clearly something is amiss - but what?

[eddiemonge]

@TheChymera what is the startup time with atom --safe?

[TheChymera]

Not much better - the time varies freely between 10-40s total it seems to me. Horrible, no?

[benogle]

Horrible, yes. It's surprising the themes take as long as they do, when it's just placing stylesheets into the dom.

[nathansobo]

@TheChymera Do you have a rotating HD? That's been an issue since our startup currently has a look of seeks.

[TheChymera]

@nathansobo yes, as I said before, I do not have an SSD. And again, I would like to repeat how absurd having latest-generation _hardware_ requirements for a text editor is.

[nathansobo]

Sorry about that. We're working on it.

[muchweb]

And again, I would like to repeat how absurd having latest-generation hardware requirements for a text editor is.

• Minimum system requirements: …
• Recommended system requirements: …
• Multiplayer requirements: …

:smiley:

[eklavya]

Has to be reduced to make it usable as a text editor on my macbook pro with rotational hard drive.

[Macsch15]

https://github.com/atom/atom/issues/2654#issuecomment-62013180
On Ubuntu 14.10, 4GB RAM and HDD (WD RED)

[nijikokun]

Minimum system requirements: …
Recommended system requirements: …
Multiplayer requirements: …

Games make sense, text editors not so much.

[gespinha]

To the developers: is the new API Freeze update address this issue? Where is this issue in the roadmap checklist? I would like to follow it, since it is probably what is keeping me from using Atom as my default code editor.

[benogle]

To the developers: is the new API Freeze update address this issue?

No. The API freeze is pretty much about API cleanup for 1.0. Performance is a 1.0 initiative. See https://discuss.atom.io/t/atom-roadmap-to-1-0/12379 for more info

[edevil]

MacBook Pro (13-inch, Late 2011)
10.10
2,4 GHz Intel Core i5
8 GB 1333 MHz DDR3
500GB HDD
I'm assuming Atom is also mining bitcoins. :)

[benogle]

That is crazy. Do you have tons of other apps running? Things that do virtually no processing look like they take an insane amount of time. 300ms for theme loading? 18s for shell load time? background tips @ 100ms? (background tips just appends a single dom node)

[muchweb]

That is crazy. Do you have tons of other apps running? (…) 18s for shell load time?

@benogle,

$ nice -n 19 atom .

Just 60 seconds? Who's slower? :smile:

[edevil]

@benogle I had other apps loaded, but the CPU(s) were pretty much idle. I had not run Atom in a day so everything had to be loaded from disk.

[edevil]

@muchweb I wish I was cheating.

[muchweb]

@edevil, hahaha, I din't doubt that! ☺ Purpose of my practical joke is to point out that there is virtually no limit _how slow_ one's program can work. It would be rather more helpful to continue discussion on _how fast_ we can get it to run.

[Ziflin]

I have a new I7 laptop w/ a 7200rpm drive and it takes 10 seconds for Atom to start. It takes < 1s for Sublime to start. With the same 3 files open in both, Sublime takes 9,148K memory in 1 process vs. Atom's 5 processes taking a total of 106,932K. I understand the differences in how they're built and all, but damn, it's still just a text editor :).

[yongkangchen]

Recommend to check this out: #4293 :sunglasses:

[nijikokun]

:boom: can confirm that #4293 really speeds things up, should be looked into, close atom after doing modifications, start atom again, takes 60 ~ 80% less time to start up.

Before: 7 ~ 10s
After: 1 ~ 2s

[sir-mulan]

This could be expected behaviour and consequently a silly question on my part, but Atom takes much longer to start up (~3.5 seconds) than it says in the Timecop (~700 ms). Provided it's not a bug, what is it that it doesn't profile and can it be improved?

(The figures are from MBA i5 running Yosemite, Atom 0.165, launched via shell atom --safe, using #4293.)

I use vim for random ad hoc edits so startup time is not such a big deal and it's much more important how it behaves once it's opened, yet it still doesn't make me throw ST3 away.

[muchweb]

@broffin, I have noticed this too. I suspect that timecop may only start counting time after atom-shell is loaded.

[helmus]

Just thought I would drop this here, cold boots are always long on average but this one took extra long. This is with the default packages and I'm using version 0.152.0

[lee-dohm]

@helmus You probably want to update to the latest version. I assume that you're on Windows since I've seen a lot of Windows users with old versions due to the Installer change:

http://blog.atom.io/2014/12/10/a-windows-installer-and-updater.html

[helmus]

@lee-dohm Turns out I actually am running the latest version. I got confused because it says 0.152.0 on the release notes as latest version. ( not sure if that's a bug ? ). When I click "Restart And Update" it says: "you are running the latest version 0.166.0".
Anyway, cold boots are still very very slow. It seems to improve somewhat after restarting once or twice, pretty strange really.

[quorth0n]

:+1: my only complaint

[Sigmanor]

First launch:

Second and others launches.

Windows 8.1
2.60 GHz i5-3230M
6 GB RAM
1TB HDD

[benogle]

That first launch is insane. It took over half a second just to load/render the theme css for each theme. Was your machine loaded up during that time?

The second run is more reasonable. It would be considerably faster without emmet or the color picker.

[50Wliu]

@benogle, here's one from a fully warmed up machine (it had been on for ~3 hours when this was taken):

This is the first Atom launch.

[kevinsawicki]

@50Wliu solid state?

[50Wliu]

Nope, normal hard drive.

[zcbenz]

One possible way to fix the speed problem on HHD is to use asar to archive all the source code files into one file, so when loading Atom will only read one file instead of reading nearly 600 files.

[dustincaruso]

just wanted to add my 2¢...

• "New Window" (blank)
• no packages or plugins (fairly new install)
• on an iMac w/ Quad Core 2.8 i7 w/ 16GB RAM

= 3.5 seconds
= really slow

[bpasero]

@kevinsawicki you say:

Pretty much, we've never really profiled Atom shell load time deeply and seen about possible
optimizations there, but that would probably be a max speedup of 100ms since the Shell load time is
usually never the bad one, the Window load time is and Atom is in complete control over that.

I did some testing with Atom shell to understand how long it takes until my main script gets control. For that I am printing the unix timestamp before launching Atom shell and then within I just have a single console.log printing the unix timestamp at that time. Here are my times on a 2014 MacBookPro running windows (Boot camp):

• Cold: 515ms
• Warm: 140ms

Compared to doing the same with a plain node.js script:

• Cold: 140ms
• Warm: 50ms

I am wondering what takes so long in Atom shell. I am not creating any renderer processes, it is just a main.js with a single console.log statement. Any ideas?

[kevinsawicki]

I am wondering what takes so long in Atom shell.

Atom Shell performance discussions should probably be taken to a new issue over on that repo.

Compared to doing the same with a plain node.js script:

Atom Shell has more going on than just node, it also loads Chromium, so comparing Atom Shell to other native .app launch times is probably better to do.

[shahril96]

For me, it's fast enough. By the way, sometimes I also got 1000+ ms but it don't bother me much.

Atom 0.179.0

OS : Ubuntu 14.04 LTS
Processor : Intel(R) Core(TM) i7-4710HQ CPU @ 2.50GHz
Memory : 7.7 GiB
Non-SSD drive

[50Wliu]

I wish mine looked like yours :cry:. ;P

[cthielen]

I'm not sure if this belongs in the same issue but using the 'atom' command while Atom is already open also temporarily shows a second Atom icon in the dock that optimally wouldn't be there.

[muchweb]

I'm not sure if this belongs in the same issue

@cthielen, I think you are better creating new issue for this.

[kylejson]

Mid 2012 Mac running yosemite on i5 8gb RAM

[edevil]

Big improvements!

[ceyhunkerti]

We are about to celebrate first year of this issue and it is still the one that is much stops users from adopting atom.

[Hollowbean]

+1, side note... Microsofts Visual Studio Code solves this for atom. Maybe someone can look at what they did and implement it back into the main atom branch?

[edevil]

+1 Good call. Hadn't noticed it.

[iclanzan]

@Hollowbean yeah, I don’t know how Microsoft did it, but VS Code is really fast to open up and has no problem handling large (and even minified) files. Tried editing a 10MB file without a problem.

[mark-hahn]

I don’t know how Microsoft did it

I assume they did not design for hackability. They said they would offer
"plug-ins" in the future. Atom was designed to
have accessible components. And we don't know how much binary microsoft
added to the system.

Atom has some serious plans to speed it up. If they pull that off it will
be the best of all worlds. Fast and hackable.

On Tue, May 5, 2015 at 10:42 AM, Sorin Iclanzan [email protected]
wrote:

@Hollowbean https://github.com/Hollowbean yeah, I don’t know how
Microsoft did it, but VS Code is really fast to open up and has no problem
handling large (and even minified) files. Tried editing a 10MB file without
a problem.

—
Reply to this email directly or view it on GitHub
https://github.com/atom/atom/issues/2654#issuecomment-99155455.

[benjiro]

Finding huge improvements after the last few builds. Keep up the good work!

[psychok7]

version 1.0 on Ubuntu 14.04 x64 it took about 4/5 seconds to load up 1 small file (no extensions) on a i7 8GB machine.

Startup performance definitely needs some love.

[xpol]

Yes, more love please. It's and editor not and IDE.

[Gabriel-p]

I'm definitely seeing a performance improvement with v1.0:

not nearly as fast as Sublime yet, but slowly getting there.

[Sigmanor]

[yeluolei]

start up too slow

[ben-sussman-zocdoc]

+1 This is the issue that is preventing me from adopting Atom as my primary editor. I experience about a ~4s latency before the text of a tiny misc.txt file is rendered. New tabs and new files are fast, but from completely closed & cold to displaying text is about 4s. I'm am using a completely vanilla atom.io install on an 2.7Ghz i7 rMBP with 16gig of Ram.

[mnquintana]

completely closed & cold to displaying text is about 4s

Is that the exact startup time? You can find out the exact startup time by opening Timecop from the Command Palette.

[ben-sussman-zocdoc]

No, that is "human experience time", measured from the time I click the misc.txt file (or launch it with Quicksilver, or launch it from the terminal) and the time that I see text displayed.

Timecop reports a significantly faster time of just under 1000ms. However it must be ignoring something because I experience >1000ms of time staring at a blank atom.io screen before the tab appears with my txt file in it.

Here is a screenshot of my Timecop output

I could make a video showing the 4s experienced latency if you require it. But this seems trivial to reproduce.

[Gabriel-p]

Yeah I get a similar experience to that of @ben-sussman-zocdoc. I just tried: atom took 18s to fully load (really, it did, I used my cell's chronometer) while Timecop reported 9.8s.

After a couple of close/open cycles, I can get it down to 5.5s vs 1.4s (chronometer vs Timecop).

AMD A8-3870 APU with Radeon(tm) HD Graphics
8Gb RAM

[Soleone]

on my rails project with around 40,000 files in total:

main offenders:

• window load time: 3s
• tree view: 2s

edit: for what it's worth the startup time is now a good bit better, i am not sure why. it's the same day and i'm in the same project:

the only differences i can think of:

• i had different files open as tabs
• i had different files/folders expanded in the tree-view

[wbyoung]

I'm seeing the same thing as @ben-sussman-zocdoc where human experience time is just a bit over 2x what Timecop reports (measured with stopwatch).

[thedaniel]

It's worth filing an issue on the timecop repo about this - if it's missing something that should be measured, it's less useful as a tool for us to diagnose problems.

[benogle]

Agreed on the timecop issue. Just speculating, but It's probably that something is happening before we can even start the clock. The reported time is at the beginning of the 'renderer' js code execution. See https://github.com/atom/atom/blob/master/static/index.js#L11 There is probably fruit to pick in the browser process as well.

[nemoDreamer]

:+1: All the devs I've talked to who didn't switch to Atom said it was because of the speed...
I adore Atom, but I have Sublime Text 3 set up as my default shell editor, so that I don't have to wait 3s+ to edit piped output, git commit messages, etc... I've got way more packages active in Sublime, but it still opens up like TextEdit (Notepad). Also it doesn't choke when editing 2000+ lines (but that's probably more the fault of plug-in developers...)

Sorry I'm not adding anything helpful to the conversation, and there _was_ a big improvement with 1.0, thanks!

[xpol]

Atom 1.0.9 on Mac mini late 2012 (16G RAM, HDD) still takes 3390ms for first time launch.

[mark-hahn]

How long does it take in safe mode? (Start with "atom --safe")

On Tue, Sep 1, 2015 at 7:10 PM, xpol [email protected] wrote:

Atom 1.0.9 on Mac mini late 2012 (16G RAM, HDD) still takes 3390ms for
first time launch.

—
Reply to this email directly or view it on GitHub
https://github.com/atom/atom/issues/2654#issuecomment-136914708.

[mnn]

With similar addons it's 27s vs. 3s. This is beyond a threshold of usability :(.

[danielmelogpi]

I'm consistently experiencing this problem, especially after a full reboot.
I can also have a very slow window reload if I delete compile-cache (understandable). I'm wondering if the use of such cache could be improved. I feel like after every reboot atom needs to do this again. If that is the case, we are missing the point of using a cache.

This was the startup time this morning:

[modest]

Let's say that there are 2 separate issues:
Issue A: Time to start Atom initially, issue #3673
Issue B: Time to create new editor window, this issue

Issue B is actually what stops me from using Atom very frequently. I use tabs sometimes, but I need multiple windows. And new windows are insanely slow to create in Atom.

Why doesn't Atom just create an invisible "hot spare" window? Always have an extra Chromium window ready for action, with Atom loaded up, completely hidden to the user. And when the user opens a document in a new window or creates a new editor window... it appears in milliseconds.

Yes, it's a little extra memory usage, but well worth it for the performance gain. Atom is great at a lot of things, but it's not the right editor to choose if you are super tight on memory.

Basically, what @DavidLGoldberg and @blixt proposed above, with no response. It seems crazy to ignore this solution.

[rattrayalex]

FWIW, as a current non-user waiting solely for this issue to be resolved before becoming a user, I would happily pay the price of the extra ram in order to be able to use this software.

+1 to @modest / @DavidLGoldberg / @blixt 's proposal

[iongion]

I have 32 GB of RAM, can't it be made to stay there and fire quickly ?
jEdit was doing such a thing and it shined(for startup-time compared to other java editors) in the early 2000s

[mark-hahn]

can't it be made to stay there and fire quickly ?

Can't you just leave it open all the time? That is the same thing. I
never close mine.

On Thu, Oct 15, 2015 at 8:20 AM, ionut stoica [email protected]
wrote:

I have 32 GB of RAM, can't it be made to stay there and fire quickly ?
jEdit was doing such a thing and it shined(for startup-time compared to
other java editors) in the early 2000s

—
Reply to this email directly or view it on GitHub
https://github.com/atom/atom/issues/2654#issuecomment-148419641.

[rattrayalex]

@mark-hahn I believe the issue is opening a new window, eg; for a separate project from the one you're already working on.

[AnthonyAmanse]

Using samsung 850 evo 500GB SSD and it loads for 1461-2000 ms. Other programs on my SSD starts up fast. Is this normal?

[koliyo]

I also have a fast workstation with lots of RAM and SSD, and Window load time is around 1500ms, using Atom 1.2 on Mac OS X.

[benogle]

The 1.3-beta that is out now has startup speed improvements see the blog post for more info. You can download the beta here.

[modest]

Atom 1.3-beta here, still takes around 2000 ms to create a new window :(

[Gabriel-p]

Sadly I see very little improvement with 1.3-beta. From cold boot to fully open it just took over 7 sec. After an open/reopen cycle I can bring it down to 2200 ms.

Sublime 3 is almost instant in my system, for comparison.

[slice]

For me, it takes about ~2000ms (~1600ms on beta) to create a window. It has improved, though. On previous versions of Atom, it took about 6-10 seconds to create a new window. (My computer is _not_ fast.)

No additional packages were installed. Running Xubuntu 15.10.
(1.3-beta on left, 1.2.4 on right)

[agauniyal]

Says ~2000ms but loads up completely in more than 5 seconds for me, even after disabling and uninstalling few essential packages.

[BladeMight]

8 sec+, why ?

[grinderX19]

Maybe it makes sense to implement something like LibreOffice's Systray Quickstarter as a workaround? It would be disabled by default.
I don't use such options for office apps as I don't work with documents much but it doesn't seem like a bad idea for Atom I use daily.

[alexandernst]

Doing what I wrote here https://github.com/atom/atom/issues/9334 would improve the situation.

[BladeMight]

@grinderX19, maybe, but what about how it does Visual Studio Quick Startup fucntion, without tray.

[BladeMight]

Or since it is using same framework that uses Chrome, why not to do like Chrome it does?
Chrome opens lighning fast, Atom(which uses same framework) opens tortoise like? This must me solved.

[nathansobo]

I think there's something dicey going on in the browser process, maybe related to our outdated approach to restricting the application to a single instance, but it's just a hunch. Problem is our browser process code has evolved from a pile of Objective-C in the days when Atom lived in a WebKit window way before Electron even existed. It needs an overhaul, unit tests, etc. It's on my radar once I overhaul our outdated build system.

[alexandernst]

@nathansobo What do you think about my suggestion in #9334. Would that help? Is it possible at all?

[nathansobo]

@alexandernst I replied on that issue. Long story short, I don't think there's a silver bullet here. We just need to chip away. Straighten out the browser process and make sure it introduces no pauses and minimize the code we require. I have no better ideas at the moment.

[controversial]

My atom is _really_ slow to startup on a 2010 MacBook Pro. Seems like it takes ~6 seconds to actually show me anything, although a blank window spawns pretty quickly. Timecop reports ~4 seconds:

[shellscape]

Mind bottling (yes, bottling) that this is still an open issue almost two years after it's been reported. Was googling for how to speed it up after it took nearly 10 seconds to open on my 2013 MBP tonight.

[mark-hahn]

this is still an open issue almost two years after it's been reported.

This isn't a bug to fix. It is a performance improvement issue which will
get better and better but never go away. Mine always opens in my laptop in
less than two seconds with about 40 packages but it will be better when it
opens in one second. Two years ago Atom took six or more seconds for me to
open. But even then it was worth it.

On Sun, Mar 27, 2016 at 8:59 PM, Andrew Powell [email protected]
wrote:

Mind bottling (yes, bottling https://www.youtube.com/watch?v=0DFBoLZC3Bw)
that this is still an open issue almost two years after it's been reported.
Was googling for how to speed it up after it took nearly 10 seconds to open
on my 2013 MBP tonight.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/atom/atom/issues/2654#issuecomment-202221893

[agauniyal]

maybe this editor is designed to work on latest & resource heavy machines only, and we're just hoping that this will work fast enough on our 2-3yrs old systems. I don't know how chrome does it, but it gets ready in no time (~1 second). Timecop shows 2-3seconds startup but editor opens up in ~8 seconds on my machine.

Note - we're not blaming someone for this issue, we're just curious and trying to find what is the cause of this slowness of atom since removing this would make it much much better primary editor.

[shellscape]

echoing the sentiments of @agauniyal. that's an excellent point about chrome's lightning quick startup by comparison. perhaps the atom team could reach out to the chrome developers group for some assistance - they might have the magic bullet.

[thomasjo]

maybe this editor is designed to work on latest & resource heavy machines only, and we're just hoping that this will work fast enough on our 2-3yrs old systems.

I'm using a mid-2012 15" MBP (Retina) machine, hence an almost 4 year old machine, and have never had any major performance issues. Atom does a fair bit of disk IO during startup, so using a good SSD instead of an antiquated, spinning rust drive does help a ton though.

Comparing Atom to Chrome is like comparing apples and kittens; it doesn't really make sense because they are trying to achieve very different things. What Chrome does is trivial in comparison to Atom (since the latter is built directly on top of the former).

perhaps the atom team could reach out to the chrome developers group for some assistance - they might have the magic bullet.

They have been involved several times, and let me assure you, there is no silver bullet. There are a multitude of many small improvements that can, and will, be made, that will gradually keep improving the performance. Performance has already improved a lot in the last year, and will likely continue to improve this year.

[prijindal]

I have something in my atom startup
It opens really fast in less than 2 seconds when i am opening a simple folder
But any folder which has npm modules takes considerable time to load.
What exactly Atom does when there are npm modules?

[controversial]

@thomasjo Yeah, but I'm using a mid-2010 MBP. I'm two years behind you, and I _do_ have any major performance issues. I've got an SSD, though.

One thing I've been noticing lately is that atom slows down a _lot_ when checking for updates. Even if I close the settings tab, it's almost unusably slow for about 2 minutes afterwards.

[thomasjo]

@The-Penultimate-Defenestrator I'm guessing what you're experiencing is related to https://github.com/atom/settings-view/issues/756.

[controversial]

@thomasjo No, I see a huge slow-down even when searching for new packages, not just while updating.

[thomasjo]

I have something in my atom startup
It opens really fast in less than 2 seconds when i am opening a simple folder
But any folder which has npm modules takes considerable time to load.
What exactly Atom does when there are npm modules?

@prijindal It doesn't do anything special with npm modules, but Atom does run through the entire directory tree of your project, and if your project has a wide and/or deep node_modules directory tree with lots of files, scanning will spend a nontrivial amount of time and resources. If you e.g. add node_modules to your project's .gitignore file, your problem should go away (assuming you've not changed the default ignored files setting in Atom).

[Ehekatl]

Supper slow on windows 10...I have stand this since atom 1.0, a brand new atom is very fast at beginning, but suddenly without install any package it start become very slow, even in safe mode

[denji]

Atom 1.7.2

[Zireael07]

Is your atom storage folder large? Maybe something in there is slowing things down... a large project?

[lee-dohm]

@Zireael07 The ~/.atom/storage folder isn't used in the same ways in v1.7.x and above. It won't become large because the things that were stored there previously aren't anymore.

[sryze]

Mine loads literally half a minute :) (Atom 1.7.3)

It's a pretty old Mac though.

[muchweb]

If you have lots of packages installed, you may try storing your .atom directory in a RAM disk. This could make reopening a bit faster. I have my /tmp directory mounted as a tmpfs.

mv ~/.atom{,-storage}
ln -s /tmp/.atom ~/.atom

// On system start-up
cp -r ~/.atom-storage /tmp/.atom

// To preserve changes (e. g. updating modules)
rsync --itemize-changes --archive --delete /tmp/.atom/ ~/.atom-storage

[odgon]

@muchweb That work for me. Thanks

[slice]

Startup time has definitely improved from Nov 2015, however this is a new laptop (1.9ghz i3)

[avm99963]

For me Atom lasted 20 seconds or more to load. But after following the steps indicated by thedaniel and thomasjo the time was reduced to 440ms, which is great hehe.

Basically what they mentioned (and I did) was removing the ~/.atom/storage/ folder and running apm rebuild-module-cache.

[denji]

If you have lots of packages installed, you may try storing your .atom directory in a RAM disk.

NVMe SSDs 100k IOPS?

[BladeMight]

After updating from version 1.5.0(which i was using for long time) to latest 1.9.0beta1, startup become 8x faster, with same packages but startup faster ~1 sec. (AMD 2x2.5 GHz)

[dthorsen]

When I open Atom 1.11.12 from the Dock on Mac OS 10.11.6 on a brand new MacBook Pro, it takes 10's of seconds to load on Window load time.

If I open it from terminal, it opens in 1 or 2 seconds. What would cause this?

[nathansobo]

@dthorsen It's caused by macOS's app nap feature. Basically the running instance of Atom goes to sleep and we can't communicate with it when a second instance is launched via the terminal. We have a fix in place on beta which should be out next week.

[ghost]

When will the faster?
Windows 10 Anniversary.
Ram 2Gb.
Intel Core i3.
Atom 1.12.3.

[nathansobo]

We're actively working on improving this but it will be a couple releases at least probably.

[ghost]

@nathansobo I see that GitKraken and VSCode use Electron but both activities seem faster and easier to install. I hope Atom will be better. I really like Atom.

[nathansobo]

Yeah, it has a lot more to do with the modular nature of Atom and the fact that we're super dynamic and flexible... lots of little paper cuts have built up over time. We'll have a tracking issue diagnosing the situation pretty soon.

[martinheidegger]

I am just putting this out there but for plugin development a lint tool like I outlined here could be used to check plugins and it would probably make the startup quite a bit faster:

It should check if my package is loaded quickly.

[50Wliu]

It should check if my package is loaded quickly.

Timecop already implements this for everyone, not just package developers.

[martinheidegger]

there is a surprising amount of packages called timecop. Which one are you referring to?

[Ben3eeE]

It is a core package. You can access it via the command timecop:view from the command palette.

[walles]

Related: https://github.com/atom/metrics/issues/70

[Xaeroxe]

So pretty early on in this issue a distinction between Atom being an IDE and being a text editor was made. For example when I launch Visual Studio I expect it to take a while to come up and in exchange for that I get a full IDE. When I just need to review a log file though without launching a code editor programs like Notepad++ are relatively instantaneous and give me what I need quickly.

I use Atom to edit code written in the Rust programming language, and as a consequence of this I have Atom setup with a collection of packages that make it feel more like an IDE, and I can clearly see in my timecop that these packages are costing me startup time. What I would like to be able to do but see no way to do in Atom as it currently exists is to have different "modes" with different lists of packages to load. For my scenario I'd have two "modes" a default mode, which doesn't load any of the Rust "IDE" packages I use and a "Rust" mode which would load the Rust IDE packages. Perhaps Atom could respond to a command line switch on launch something like "--mode=Rust" or perhaps after the default mode is launched you could have a "Mode" dropdown in the menu bar which lets you select a particular mode. These modes would have to be user defined of course.

[Xaeroxe]

Also, is Atom using this V8 functionality to its full extent? http://v8project.blogspot.com/2015/07/code-caching.html If not, caching the compilation results of packages and using them if the package hasn't been modified could help with startup time.

EDIT: This is likely already covered by the APM module caching but I'm going to leave this comment here as I'm not sure if that is the same thing as this.

EDIT 2: I'm actually not so sure about the APM module caching anymore, as that seems to only cache the results of compiling CoffeeScript to JavaScript, not the result of compiling JavaScript from the V8 engine. If we aren't already caching the output from V8 then this could potentially give a huge performance boost to Atom. I think I'm going to this weekend determine
A: Does Atom currently store a V8 cache? and if not
B: Should that caching functionality be added to Electron, Atom or both?

Then I'll see if I can make a pull request to do this.

[prijindal]

@Xaeroxe23 that is a very cool feature. Something like that will also be helpful if you are using atom for two different programming languages or for two different frameworks.
Then you can simply save your configurations and plugins that need to load for that language and will reduce the startup time considerably, I suppose

[mildocjr]

A few years later and still wish Atom would launch faster. On Windows 10 64-bit, with a quad core i7 @2.5Ghz 16 GB of RAM, from taskbar icon click to initial window launch it takes 8 seconds. From window launch to useable it takes another 4.5 seconds (12.5 seconds in total) from a near fresh install. Would it be possible to rework the initial launch to load the window and document first, followed by the specific plug-ins needed for syntax highlighting and auto-completion? The source tree could be loaded next, followed by any plug-ins that associate with other files in the source tree, and finally the remaining plug-ins that may not be used at all. Atom has been my favorite code editor since I found out about it a few years ago. The only reason I install Notepad++ is for previewing files quickly because of Atom's launch speed.

[nathansobo]

Current work on launch speed is focused on snapshotting core code and bundled packages, initially to reduce time spent requiring JS but subsequently to remove other overhead. We need to modernize multiple packages in order to include them in the snapshot and you can track that work in https://github.com/atom/atom/issues/13254.

Short answer, we're working on it but there's no immediate silver bullet. Startup time is influenced by multiple factors.

[seanfuture]

Would it be possible to completely defer project loading and window state? ( assuming shell loading is required, but even defer that too if possible ) .. Often times we're simply opening a single file and need to be able to access it as quickly as possible. Right now Atom opens in about 2 seconds on a modern high-end MacBook and these 3 aspects as reported by Timecop seem to be the sizable portion. It would be huge if async processing of these major items could happen after Atom displays, file is opened and visibly accessible. Thanks for your insight @nathansobo.

[nathansobo]

@seanfuture The devil is always in the details. These may be good ideas but would take time to investigate, so I can't really give you any specific insight. We'll circle back around to startup time eventually. In the meantime if you'd like to experiment with these ideas I'd be interested in your findings.

[rafrafek]

Atom 1.28.1 startup is so slow it takes about 8-10 seconds on SSD with project like 30 lines of html and without any javascript (main.js on my screenshot is an empty file). I don't have any non-core package installed.
For example VS Code starts < 1s on my machine. (SSD SanDisk Ultra II 240GB Sata3, Ryzen 1600 x6 core, 16 GB ram).
I think something is really really wrong with Atom startup time.

[Jacalz]

To be quite honest, this is still really slow. Would like to see this improved dramatically, just look at vscode, it has way better startup time...

[stale[bot]]

Thanks for your contribution!

This issue has been automatically marked as stale because it has not had recent activity. Because the Atom team treats their issues as their backlog, stale issues are closed. If you would like this issue to remain open:

1. Verify that you can still reproduce the issue in the latest version of Atom
2. Comment that the issue is still reproducible and include:
   
   
   
   • What version of Atom you reproduced the issue on
   
   
   • What OS and version you reproduced the issue on
   
   
   • What steps you followed to reproduce the issue
   
   

Issues that are labeled as triaged will not be automatically marked as stale.

[benwhalley]

It might be worth keeping this issue open as startup time is still not that snappy (latest build, OS X).

[MartinX3]

Yes, it's way too much. (Latest build, Arch Linux)