New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Editor window startup is slow #2654

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

Comments

Projects
None yet
@renatodex

renatodex commented Jun 18, 2014

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

This comment has been minimized.

Show comment
Hide comment
@benogle

benogle Jun 18, 2014

Contributor

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.

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

This comment has been minimized.

Show comment
Hide comment
@renatodex

renatodex Jun 18, 2014

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?

renatodex commented Jun 18, 2014

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

This comment has been minimized.

Show comment
Hide comment
@benogle

benogle Jun 18, 2014

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@benogle

benogle Jun 18, 2014

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@renatodex

renatodex Jun 18, 2014

Thanks Ben, i appreciate your help!

renatodex commented Jun 18, 2014

Thanks Ben, i appreciate your help!

@benogle

This comment has been minimized.

Show comment
Hide comment
@benogle

benogle Jun 18, 2014

Contributor

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?

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

This comment has been minimized.

Show comment
Hide comment
@renatodex

renatodex Jun 18, 2014

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

renatodex commented Jun 18, 2014

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

This comment has been minimized.

Show comment
Hide comment
@benogle

benogle Jun 19, 2014

Contributor

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.

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

This comment has been minimized.

Show comment
Hide comment
@lee-dohm

lee-dohm Jun 19, 2014

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.

Member

lee-dohm commented Jun 19, 2014

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

This comment has been minimized.

Show comment
Hide comment
@countergram

countergram Jul 24, 2014

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.

countergram commented Jul 24, 2014

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

This comment has been minimized.

Show comment
Hide comment
@kevinsawicki

kevinsawicki Jul 24, 2014

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.

Member

kevinsawicki commented Jul 24, 2014

@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

This comment has been minimized.

Show comment
Hide comment
@batjko

batjko Jul 25, 2014

Contributor

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

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

This comment has been minimized.

Show comment
Hide comment
@starquake

starquake Jul 25, 2014

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

starquake commented Jul 25, 2014

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

This comment has been minimized.

Show comment
Hide comment
@countergram

countergram Jul 25, 2014

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.

countergram commented Jul 25, 2014

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

This comment has been minimized.

Show comment
Hide comment
@kevinsawicki

kevinsawicki Jul 25, 2014

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.

Member

kevinsawicki commented Jul 25, 2014

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

This comment has been minimized.

Show comment
Hide comment
@rsanchezsaez

rsanchezsaez Jul 25, 2014

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.

rsanchezsaez commented Jul 25, 2014

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

This comment has been minimized.

Show comment
Hide comment
@countergram

countergram Jul 25, 2014

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.

countergram commented Jul 25, 2014

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

This comment has been minimized.

Show comment
Hide comment
@xpol

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

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

This comment has been minimized.

Show comment
Hide comment
@renatodex

renatodex Aug 13, 2014

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!

renatodex commented Aug 13, 2014

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

This comment has been minimized.

Show comment
Hide comment
@Zren

Zren Aug 14, 2014

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

Zren commented Aug 14, 2014

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

@odensc

This comment has been minimized.

Show comment
Hide comment
@odensc

odensc Aug 23, 2014

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

odensc commented Aug 23, 2014

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

@tosh

This comment has been minimized.

Show comment
Hide comment
@tosh

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

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

This comment has been minimized.

Show comment
Hide comment
@ceyhunkerti

ceyhunkerti Aug 31, 2014

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.

ceyhunkerti commented Aug 31, 2014

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

This comment has been minimized.

Show comment
Hide comment
@karolszk

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

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

This comment has been minimized.

Show comment
Hide comment
@Giancarlos

Giancarlos Oct 1, 2014

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?

Giancarlos commented Oct 1, 2014

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?

@lee-dohm

This comment has been minimized.

Show comment
Hide comment
@lee-dohm

lee-dohm Apr 26, 2016

Member

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

Member

lee-dohm commented Apr 26, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@sryze

sryze May 18, 2016

Contributor

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.

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

This comment has been minimized.

Show comment
Hide comment
@muchweb

muchweb May 18, 2016

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

muchweb commented May 18, 2016

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

This comment has been minimized.

Show comment
Hide comment
@odgon

odgon Jun 1, 2016

@muchweb That work for me. Thanks

odgon commented Jun 1, 2016

@muchweb That work for me. Thanks

@slice

This comment has been minimized.

Show comment
Hide comment
@slice

slice Jun 8, 2016

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

2016-06-08-16 23 33

slice commented Jun 8, 2016

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

2016-06-08-16 23 33

@avm99963

This comment has been minimized.

Show comment
Hide comment
@avm99963

avm99963 Jul 24, 2016

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.

avm99963 commented Jul 24, 2016

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

This comment has been minimized.

Show comment
Hide comment
@denji

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

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

This comment has been minimized.

Show comment
Hide comment
@BladeMight

BladeMight Aug 1, 2016

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)

BladeMight commented Aug 1, 2016

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

This comment has been minimized.

Show comment
Hide comment
@dthorsen

dthorsen Nov 1, 2016

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

dthorsen commented Nov 1, 2016

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

This comment has been minimized.

Show comment
Hide comment
@nathansobo

nathansobo Nov 1, 2016

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.

Contributor

nathansobo commented Nov 1, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Nov 16, 2016

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

atom-timecop

ghost commented Nov 16, 2016

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

atom-timecop

@nathansobo

This comment has been minimized.

Show comment
Hide comment
@nathansobo

nathansobo Nov 16, 2016

Contributor

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

Contributor

nathansobo commented Nov 16, 2016

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

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Nov 16, 2016

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

ghost commented Nov 16, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@nathansobo

nathansobo Nov 16, 2016

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.

Contributor

nathansobo commented Nov 16, 2016

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

This comment has been minimized.

Show comment
Hide comment
@martinheidegger

martinheidegger Nov 16, 2016

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.

martinheidegger commented Nov 16, 2016

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

This comment has been minimized.

Show comment
Hide comment
@50Wliu

50Wliu Nov 16, 2016

Member

It should check if my package is loaded quickly.

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

Member

50Wliu commented Nov 16, 2016

It should check if my package is loaded quickly.

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

@martinheidegger

This comment has been minimized.

Show comment
Hide comment
@martinheidegger

martinheidegger Nov 16, 2016

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

martinheidegger commented Nov 16, 2016

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

@Ben3eeE

This comment has been minimized.

Show comment
Hide comment
@Ben3eeE

Ben3eeE Nov 16, 2016

Member

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

Member

Ben3eeE commented Nov 16, 2016

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

@bryphe bryphe referenced this issue Dec 7, 2016

Closed

Direction of Oni? #35

@walles

This comment has been minimized.

Show comment
Hide comment
@walles

walles commented Dec 17, 2016

Related: atom/metrics#70

@Xaeroxe

This comment has been minimized.

Show comment
Hide comment
@Xaeroxe

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

This comment has been minimized.

Show comment
Hide comment
@Xaeroxe

Xaeroxe Jan 9, 2017

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.

Xaeroxe commented Jan 9, 2017

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

This comment has been minimized.

Show comment
Hide comment
@prijindal

prijindal Jan 9, 2017

@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

prijindal commented Jan 9, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@mildocjr

mildocjr Jan 12, 2017

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

mildocjr commented Jan 12, 2017

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

This comment has been minimized.

Show comment
Hide comment
@nathansobo

nathansobo Jan 13, 2017

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.

Contributor

nathansobo commented Jan 13, 2017

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.

@seanfuture

This comment has been minimized.

Show comment
Hide comment
@seanfuture

seanfuture Jun 19, 2017

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.

image

seanfuture commented Jun 19, 2017

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.

image

@nathansobo

This comment has been minimized.

Show comment
Hide comment
@nathansobo

nathansobo Jul 3, 2017

Contributor

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

Contributor

nathansobo commented Jul 3, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@rafrafek

rafrafek Jul 12, 2018

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.
atom_slow_startup_1-28-1

rafrafek commented Jul 12, 2018

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.
atom_slow_startup_1-28-1

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