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)
├── activate-power-mode@2.6.0
├── atom-beautify@0.30.9
├── atom-ide-ui@0.7.0
├── atom-ternjs@0.18.3
├── busy-signal@1.4.3
├── file-icons@2.1.15 (Updated today, FWIW)
├── highlight-selected@0.13.1
├── hyperclick@0.1.5
├── iam-syntax@0.1.5
├── ide-css@0.2.0
├── ide-go@0.4.0
├── ide-html@0.4.1
├── ide-json@0.1.0
├── intentions@1.1.5
├── language-powershell@4.0.0
├── language-terraform@0.8.1
├── linter@2.2.0 (disabled)
├── linter-js-standard@4.1.0
├── linter-jsonlint@1.3.0
├── linter-ui-default@1.6.10
├── multi-cursor@2.1.5
├── open-recent@5.0.0
├── pigments@0.40.2
└── project-manager@3.3.5 (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.