Atom will take upwards of 10-15 seconds to load for me, and I’m trying to figure out what’s taking so long. I know it does record initialization times for packages (the “This package added X to startup time”), but it doesn’t display that in any central location. Is there anything that exists to help me debug that? Specifically, a full profile would be useful, not simply a listing of startup times, because those just tell me which are taking the longest to boot, not how much of that is FS or Atom API overhead.
I do have a few suspects, but startup in safe mode isn’t quite instant, either, so I’m trying to figure out what’s core, what’s overhead, and what’s package-related. I’d also like to figure out if they’re being initialized concurrently or not. Of course, there’s no obvious way for me to simply pass flags to the worker, so I’m kind of lost as to what it’d be.
Here’s some of the worst offenders I’ve identified. For context, this was run on a small-ish (10K SLoC) project with exclusively vanilla JS (targeting mostly Node), Pug, and Stylus with Git + ESLint + npm set up. The ESLint config just uses a personal config that has 0 dependencies. The package.json file is itself private and not especially large. No files were implicitly opened, but the project has been opened before. So not much interesting going on here.
- 912ms: Atom TypeScript, which does a lot of things I feel probably belong off-thread since it’s not critical to the file itself. Also, this was run on a project that doesn’t use TypeScript at all, so that’s a giant question mark.
- 884ms: autocomplete-paths, which indexes the whole project on startup and has a tendency to bail on large projects. (This step really belongs off the main thread, and it might be better optimizable by just using Glob, Chokidar, and manually building directory objects.)
- 1509ms: build, which I just uninstalled. (I no longer use this.)
- 1609ms: Linter. This startup time seems absurd, but it’s spending time in other packages. I can’t really tell from this how much is Linter and how much is other packages.
- 512ms: Linter’s default UI. This genuinely doesn’t make sense.
- 956ms: Emmet, which I do actively use. The long startup time doesn’t quite make sense, though.
- 756ms: Minimap. Streaming access to the grammar matching algorithm could make this viable to cut the overhead down to almost nothing, and this really shouldn’t be doing anything significant on initialization. (It also apparently has other perf issues.) I’m curious now and just filed this issue.
- 631ms: Atom Linter’s Minimap plugin. This makes no more sense than the startup time for Linter’s default UI.
- 671ms: file-icons, which is incredibly useful. The startup time seems a bit odd, though, but is a known issue, thankfully.
- 1095ms: Project Manager. Not sure how much of this is actually Project Manager logic and how much of this is spent in Atom land. And this is what the profile is for.
- 678ms: GitHub integration. Don’t use this much, so it’s 678ms of uselessness for me. It’s also the only core package on this list.
- I have about a dozen or so packages loading in the 200-500ms range, which likely has a major influence. These would be hard to spot normally, but a profile would lay the root cause of their slowdown very bare.