Improve package loading performance

[abdonrd]

I use Timecop to see the information about where time is spent while Atom loads and find this problem:

[sindresorhus]

Help welcome :)

[florianb]

I'm taking this issue. :racehorse:

[florianb]

Tests are implemented currently - unfortunately the measurements are significantly lower than in a production-environment. The test currently fails with a loadtime of 9-14ms depending on the run.

Unless we're able to test the real behavior i hope that our measures to tune editorconfig which then will pass the test change the production behavior as expected, too.

[florianb]

I created a first draft of the performance-optimization (https://github.com/florianb/atom-editorconfig/tree/iss66). Unfortunately i'm not satisfied with the results.

Strangely, when playing around with the different components i found out that having Xo as devDependency the whole load/activation-process slows down. I currently have no idea why this happens - probably @sindresorhus has?

However - i will do some further investigations. :eyeglasses:

[sindresorhus]

Do you happen to have atom-linter-xo installed?

You can do more advanced perf profiling in Dev Tools.

[florianb]

Yes, i use atom-linter-xo. I haven't used the Chrome-Dev-Profiler.. but i guess that's just something i have to learn now.. :dancers:

[sindresorhus]

The framegraph is your friend https://addyosmani.com/blog/devtools-flame-charts/

[florianb]

Great - thanks! :clap:

[florianb]

Okay - first riddle solved, calling workspace.observeTextEditors consumes 92% of the activation-time.

I will try to find out on which event we could try to safely rely on, in order to manage not missing any spawning editors.

[florianb]

Okay - i did some further tests. Relying on other events will break the functionality.

There are two facts we have to accept. At first, due to the lazy-load-mechanisms of Atom, the requirements for observerTextEditors will get into our Timecop-account as long as editorconfig is accessing that event-subscription first.

Secondly, Timecop-measurements differ from machine to machine, from environment to environment. This makes the whole issue untestable. I therefore put a upper load limit of 50ms into action. This should prevent future changes which cause long load-times.

[Arcanemagus]

Btw @florianb three things about load times:

• Atom by default doesn't install devDependencies when a package is installed regularly, so xo being listed shouldn't affect a normal installation
• Atom run through --dev mode loads all dependencies regardless of if the package's code actively uses them.
• Atom package load time is dependent on the list of dependencies installed, regardless of when and/or if they are being loaded. You can see some hard data on that here, note that apm install there is from running apm install within the package directory (not installing from within Atom or running apm installl package-name). Also the difference between apm install and npm install is due to that test having been run with npm@3 which flattens the directory structure as much as possible, while apm is based on npm@2 which uses a hierarchical structure that apparently takes far longer to parse.

tl;dr: Having xo there shouldn't affect production installs :stuck_out_tongue: