Editor window startup is slow #2654

Open
renatodex opened this Issue Jun 18, 2014 · 240 comments

Projects

None yet
@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

@renatodex renatodex changed the title from Atom slower than Mate to Atom slower than Textmate Jun 18, 2014
@benogle
Contributor
benogle commented Jun 18, 2014

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.

@benogle benogle changed the title from Atom slower than Textmate to Startup time is slow Jun 18, 2014
@benogle benogle changed the title from Startup time is slow to Editor window startup is slow Jun 18, 2014
@benogle benogle added the performance label Jun 18, 2014
@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
Contributor
benogle commented Jun 18, 2014

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
Contributor
benogle commented Jun 18, 2014

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
Contributor
benogle commented Jun 18, 2014

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
Contributor
benogle commented Jun 19, 2014

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
Member

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
Member

@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
Contributor
batjko commented Jul 25, 2014

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
Member

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
xpol commented Aug 13, 2014

(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
Zren commented Aug 14, 2014

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

@thesbros

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

@tosh
tosh commented Aug 28, 2014

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
karolszk commented Sep 8, 2014

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
ddlsmurf commented Oct 1, 2014

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

@muchweb
muchweb commented Oct 1, 2014

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
kirualex commented Oct 1, 2014

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
tmikaeld commented Oct 1, 2014

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
muchweb commented Oct 1, 2014

@starquake, I confirm, it does opens really fast on a fast machine (i7, SDD). But so does everything else πŸ˜„.

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

@JacobEdelman

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
necaris commented Oct 1, 2014

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 πŸ‘

@muchweb
muchweb commented Oct 1, 2014

@SchizoDuckie, yeah, NPM is well-known for raping hard drives πŸ˜ƒ

@skrat
skrat commented Oct 1, 2014

~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 notifications@github.com 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
#2654 (comment).

@Zren
Zren commented Oct 1, 2014

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
tobyl commented Oct 1, 2014

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@879e1ff

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

@swang
swang commented Oct 1, 2014

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
Contributor

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
Member

I am working on implementing a module cache in ~/.atom/packages/node_modules for packages to share, atom/apm#200

@kevinsawicki
Member

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
Contributor

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
Member

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
karolszk commented Oct 1, 2014

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
blixt commented Oct 1, 2014

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
ajmath commented Oct 1, 2014

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
Contributor
benogle commented Oct 1, 2014

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

@ajmath
ajmath commented Oct 1, 2014

@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

@kevinsawicki kevinsawicki was assigned by benogle Oct 1, 2014
@benogle
Contributor
benogle commented Oct 1, 2014

Thanks for the screenshot.

@kevinsawicki has been and is currently working on this. Progress: #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
Contributor

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

@thesbros

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

@thedaniel
Contributor

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

@thesbros

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

@benogle
Contributor
benogle commented Oct 17, 2014

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

@thesbros

@benogle Mechanical / Spinning.

@benogle
Contributor
benogle commented Oct 17, 2014

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

@benogle
Contributor
benogle commented Oct 17, 2014

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

@thedaniel
Contributor

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

@thomasjo
Member

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
Member

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

@thesbros

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
Member

@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
Member

@thesbros Nice! πŸ‘

@tobyl
tobyl commented Oct 17, 2014

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

@mark-hahn
Contributor

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 notifications@github.com
wrote:

@thesbros https://github.com/thesbros Nice! [image: πŸ‘]

β€”
Reply to this email directly or view it on GitHub
#2654 (comment).

@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
Contributor

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
Member
50Wliu commented Oct 17, 2014

Before:
timecop-before

After:
timecop-after

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

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
Contributor
benogle commented Oct 17, 2014

@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
Contributor

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
Member

@mark-hahn They are, a _atomModuleCache field

Linked packages aren't affected though.

@mark-hahn
Contributor

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 notifications@github.com
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
#2654 (comment).

@kevinsawicki
Member

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
Contributor

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 <
notifications@github.com> 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

image

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
nuivall commented Oct 20, 2014

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

@kevinsawicki
Member

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
Member

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

@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
edevil commented May 4, 2015

+1 Good call. Hadn't noticed it.

@iclanzan
iclanzan commented May 5, 2015

@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
Contributor

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 notifications@github.com
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
#2654 (comment).

@benjiro
benjiro commented May 10, 2015

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

image

@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
xpol commented Jun 27, 2015

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

@Gabriel-p

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

captura de pantalla de 2015-06-27 01 12 39

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

@yeluolei
yeluolei commented Jul 1, 2015

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
Member

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
screen shot 2015-07-01 at 10 05 36 pm
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
Soleone commented Jul 2, 2015

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

image

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:

image

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
wbyoung commented Jul 2, 2015

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

captura de pantalla 2015-07-02 a las 1 55 03 pm

@thedaniel
Contributor

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
Contributor
benogle commented Jul 2, 2015

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

πŸ‘ 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!

@kevinsawicki kevinsawicki removed their assignment Aug 7, 2015
@xpol
xpol commented Sep 2, 2015

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

@mark-hahn
Contributor

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

On Tue, Sep 1, 2015 at 7:10 PM, xpol notifications@github.com 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
#2654 (comment).

@mnn
mnn commented Sep 17, 2015

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:
atom-superlento

@modest
modest commented Oct 14, 2015

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
iongion commented Oct 15, 2015

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
Contributor

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 notifications@github.com
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
#2654 (comment).

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

@kolis
kolis commented Nov 17, 2015

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
Contributor
benogle commented Nov 17, 2015

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
modest commented Nov 19, 2015

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.

@sliceofcode

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

@agauniyal

2016-01-15-180750_1366x768_scrot

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 #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
Contributor

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
Contributor

@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
Contributor

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 notifications@github.com
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
#2654 (comment)

@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
Member

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
Member

@The-Penultimate-Defenestrator I'm guessing what you're experiencing is related to atom/settings-view#756.

@controversial

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

@thomasjo
Member

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
Ehekatl commented Apr 24, 2016

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
slow
slow2

@denji
denji commented Apr 25, 2016 edited

Atom 1.7.2
timecop

@Zireael07

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

@lee-dohm
Member
lee-dohm commented Apr 26, 2016 edited

@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
Contributor
sryze commented May 18, 2016

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

screen shot 2016-05-18 at 15 07 27

It's a pretty old Mac though.

@muchweb
muchweb commented May 18, 2016 edited

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
@4p
4p commented Jun 1, 2016 edited

@muchweb That work for me. Thanks

@sliceofcode
sliceofcode commented Jun 8, 2016 edited

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

2016-06-08-16 23 33

@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
denji commented Jul 24, 2016

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
dthorsen commented Nov 1, 2016 edited

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.
screen shot 2016-11-01 at 11 02 16 am

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

screen shot 2016-11-01 at 11 02 42 am

@nathansobo
Contributor

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

@torn4dom4n
Contributor

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

atom-timecop

@nathansobo
Contributor

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

@torn4dom4n
Contributor

@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
Contributor

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
Member
50Wliu commented Nov 16, 2016 edited

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
Member
Ben3eeE commented Nov 16, 2016

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

@extr0py extr0py referenced this issue in extr0py/oni Dec 7, 2016
Open

Direction of Oni? #35

@walles
walles commented Dec 17, 2016

Related: atom/metrics#70

@Xaeroxe
Xaeroxe commented Jan 9, 2017

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
Xaeroxe commented Jan 9, 2017 edited

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.

image

@nathansobo
Contributor

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

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment