Activaton times consistently exceeding 2000ms

[Ray-B]

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

[Ray-B]

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?

[Alhadis]

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

[repl-raymond-bolander]

It's the project-manager plugin - I was referring to the git repo name: https://github.com/danielbrodin/atom-project-manager

[Alhadis]

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.

[Ray-B]

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)

[Alhadis]

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.

[Alhadis]

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

[Jacalz]

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

[dead-claudia]

Just noticed this is a dupe of #565.