Editor window startup is slow

[renatodex]

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

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

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

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

][`s

[benogle]

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

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

[renatodex]

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

[benogle]

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

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

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

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

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

[benogle]

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

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

[renatodex]

Thanks Ben, i appreciate your help!

[benogle]

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

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

[renatodex]

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

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

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

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

][`s

[benogle]

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

[lee-dohm]

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

TabsToSpaces = null
tabsToSpaces = null

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

# ... snip ...

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

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

[countergram]

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

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

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

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

[kevinsawicki]

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

[batjko]

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

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

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

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

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

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

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

Just thinking out loud here...

[starquake]

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

Anyway, a splash screen might help.

Also just thinking out loud...

[countergram]

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

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

[kevinsawicki]

Is this a design decision or a limitation of Chrome?

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

[rsanchezsaez]

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

[countergram]

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

[xpol]

(Tried on Windows)

The current version 0.120.0 is still too much slow.

It's no match for Sublime Text 3.

Can we catch up with Sublime Text 3?

[renatodex]

Totally agree with batjko.

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

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

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

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

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

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

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

[Zren]

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

[odensc]

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

[tosh]

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

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

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

[ceyhunkerti]

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

[karolszk]

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

[Giancarlos]

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

[martinheidegger]

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

It should check if my package is loaded quickly.

[50Wliu]

It should check if my package is loaded quickly.

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

[martinheidegger]

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

[Ben3eeE]

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

[walles]

Related: atom/metrics#70

[Xaeroxe]

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

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

[Xaeroxe]

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

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

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

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

[prijindal]

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

[mildocjr]

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

[nathansobo]

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

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

[seanfuture]

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

[nathansobo]

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

[rafrafek]

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

[Jacalz]

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

[stale]

Thanks for your contribution!

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

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

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

[benwhalley]

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

[MartinX3]

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

[boredhero]

Yeah, I'd just like to bump this as well and add my +1 (Latest build, Arch Linux). It's ridiculous that with an SSD, Ryzen 3600, Fury X, and 16GB of ram it takes ~5-7 seconds to launch atom. I primarily use atom to edit small files when nano won't cut it, but if it's going to take longer to open it than VSCode then it's not worth it.

[ThatXliner]

Same. I use vim for extremely snappy edits, VS Code for debugging, and Atom for everything else. I hate vim. I really want to replace it with Atom. Is the init script execution already asynchronous?

[ventr1x]

5-7 seconds? On a maxed out Mac M1 it takes about 30 seconds. That's what we get for the decline of competency and the rise of cheap, fast packed web apps. Even in software dev people keep killing quality over easier and faster profits.

[Xaeroxe]

@ventr1x that's running emulated. Please reconsider your tone when making comments, you're not making friends or progress with that attitude.

[MartinX3]

@Xaeroxe In our opinion these multi platform electron website apps are a step backwards in terms of cpu, ram, disk storage and battery usage. Electron apps running their own chromium browser.
But hey, they are multi platform and html and javascript, etc.

[Xaeroxe]

I'm not here to talk about the performance of electron and whether it's good or bad. I'm here to remind people that

1. Open source maintainers owe you nothing.
2. Wandering into an issue tracker and calling everyone incompetent is never useful.

If you don't like Electron, why are you here? There are non-Electron editors out there, and Atom is always going to be an Electron product. Changing that would require starting from scratch, at which point you're no longer hacking on Atom. I don't know what you're trying to accomplish by bringing the Electron discussion here.

[MartinX3]

I dislike safe-spaces, they kill progress of any kind.
So I write critics about stuff I tried, but not use anymore, because of its disadvantages.

[ventr1x]

It's not running "emulated".
Electron supports M1 for over a year "natively" now.
The same issue exists on my I9 MBP 2018.
Other Electron apps (including ones I developed) do not, even remotely, have such issues - like the mentioned VSCode.

Issues without solution, disccusions or ask for help - instead simple closures and shoving under the rug -, existing for 7+ years.. yep, I cannot call that a beacon of competence.

[icecream17]

It's more like there's not enough contributors. There's 7 pull requests right now and VSCode had 30+ commits today, so that's not a fair comparison. 7+ years is totally normal. In fact, I chose a random number between 1 and 100000, and this vscode issue took 1 year ^oof to resolve (probably worse than average but still) microsoft/vscode#28965.

/rant (really unproductive comments here huh)

Anyways...

I also used the javascript profiler in the console, and here's the results when I did the reload window command: