Skip to content
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

Closed
renatodex opened this issue Jun 18, 2014 · 247 comments
Closed

Editor window startup is slow #2654

renatodex opened this issue Jun 18, 2014 · 247 comments

Comments

@renatodex
Copy link

@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 Atom slower than Mate Atom slower than Textmate Jun 18, 2014
@benogle
Copy link
Contributor

@benogle 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 Atom slower than Textmate Startup time is slow Jun 18, 2014
@benogle benogle changed the title Startup time is slow Editor window startup is slow Jun 18, 2014
@benogle benogle added the performance label Jun 18, 2014
@renatodex
Copy link
Author

@renatodex 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
Copy link
Contributor

@benogle 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
Copy link
Contributor

@benogle 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
Copy link
Author

@renatodex renatodex commented Jun 18, 2014

Thanks Ben, i appreciate your help!

@benogle
Copy link
Contributor

@benogle 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
Copy link
Author

@renatodex 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
Copy link
Contributor

@benogle 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
Copy link
Member

@lee-dohm 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
Copy link

@countergram 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
Copy link
Member

@kevinsawicki 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
Copy link
Contributor

@batjko 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
Copy link

@starquake 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
Copy link

@countergram 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
Copy link
Member

@kevinsawicki 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
Copy link

@rsanchezsaez 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
Copy link

@countergram 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
Copy link

@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
Copy link
Author

@renatodex 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
Copy link

@Zren Zren commented Aug 14, 2014

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

@odensc
Copy link

@odensc 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
Copy link

@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
Copy link

@ceyhunkerti 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
Copy link

@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
Copy link

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

@denji
Copy link

@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
Copy link

@BladeMight 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
Copy link

@dthorsen 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
Copy link
Contributor

@nathansobo 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
Copy link

@ghost ghost commented Nov 16, 2016

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

atom-timecop

@nathansobo
Copy link
Contributor

@nathansobo nathansobo commented Nov 16, 2016

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

@ghost
Copy link

@ghost 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
Copy link
Contributor

@nathansobo 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
Copy link

@martinheidegger 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
Copy link
Member

@50Wliu 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
Copy link

@martinheidegger martinheidegger commented Nov 16, 2016

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

@Ben3eeE
Copy link
Member

@Ben3eeE Ben3eeE commented Nov 16, 2016

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

@walles
Copy link

@walles walles commented Dec 17, 2016

Related: atom/metrics#70

@Xaeroxe
Copy link

@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
Copy link

@Xaeroxe 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
Copy link

@prijindal 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
Copy link

@mildocjr 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
Copy link
Contributor

@nathansobo 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
Copy link

@seanfuture 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
Copy link
Contributor

@nathansobo 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
Copy link

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

@Jacalz
Copy link

@Jacalz Jacalz commented Nov 24, 2018

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

@stale
Copy link

@stale stale bot commented Nov 24, 2019

Thanks for your contribution!

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

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

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

@stale stale bot added the stale label Nov 24, 2019
@stale stale bot closed this Dec 8, 2019
@benwhalley
Copy link

@benwhalley benwhalley commented Jan 9, 2020

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

@MartinX3
Copy link

@MartinX3 MartinX3 commented Aug 24, 2020

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.