atom
atom copied to clipboard
file-icons
Activaton times consistently exceeding 2000ms
Version Info Running version 2.1.14 of the file-icons package. Running version 1.23.1 x64 of Atom, on Windows.
Observations
- Timecop is marking file-icons as 30ms for package load, and 2241ms for package activation.
- Package activation is for a fresh instance of Atom, with no project folders "added" and the tree view not visible (because no projects are added to the work-space).
- In recent weeks I've also observed cases where package activation exceeded 6000ms
There are some additional packages installed including atom-ide-ui, etc. not sure if they make use of or perhaps interfere in some way with file-icons during activation, but I wanted to add this note in case it is worth investigating.
Let me know if there is any additional debugging information I can provide to add clarity to this issue.
And a general shout-out for the efforts that have been made so far to maximize the speed of this useful package. :)
As an experiment, I disabled various packages one by one to check the loading time.
By far the biggest contributor to file-icons activation time was a package called atom-project-manager.
Activation time for file-icons went from 2k-6k ms down to 180ms.
It's interesting that another package can brick file-icons. Maybe there is a way to isolate the package better?
Alright, that's definitely not normal. It's no secret that this package has a slow activation time, but that ridiculous. Can you link me to the atom-project-manager package, please? I'm only aware of project-manager (without the atom- prefix).
It's the project-manager plugin - I was referring to the git repo name: https://github.com/danielbrodin/atom-project-manager
Could you provide a list of every active package, please? You can obtain it by running apm ls -i in a terminal.
I've never experienced any additional lag with project-manager, but it's possible that the catalyst is another package which depends on project-manager to be active.
Community Packages (24) ├── [email protected] ├── [email protected] ├── [email protected] ├── [email protected] ├── [email protected] ├── [email protected] (Updated today, FWIW) ├── [email protected] ├── [email protected] ├── [email protected] ├── [email protected] ├── [email protected] ├── [email protected] ├── [email protected] ├── [email protected] ├── [email protected] ├── [email protected] ├── [email protected] (disabled) ├── [email protected] ├── [email protected] ├── [email protected] ├── [email protected] ├── [email protected] ├── [email protected] └── [email protected] (disabled)
Well, then... scratch that theory, I suppose. 😕
Could you profile the startup time using --profile-startup, to see which calls are eating up most of the execution time? Something similar to what @hansonw provided with #687.
@Ray-B, are you still witnessing this? There've been code cleanups this year which eradicated a lot of problematic cruft, which may have ameliorated the startup lag.
I only get a 606ms time for this, doesn't really look all that bad. Could probably be improved on but again, not too bad...
