Horrible activation performance
Closed this issue · 8 comments
Version
4.0.5 @ Atom 1.8.0 @ Win7 Prof x64
Issue
ATM linter-jscs really slows my atom startup down. I see package activation times of 1 to 1.5 seconds. This is when opening a C project directory in atom, so JSCS should actually not have to do much here.
Ok, so I did some testing and of the 1115 ms it took to require('linter-jscs'), 910 ms were spent on requiring jscs (which in turn spent a 542 ms to load cst), while another 192 ms were spent on loading globule.
The disk used in this test is a Samsung 850 Evo, my CPU is rather shabby though (Athlon II X4 635)
Well, FWIW it's not your fault 😄
One could question if globule is worth the load time penalty but jscs is definitely the bigger problem.
Ah ha, you are getting caught by the same trap many others are when talking about this. That has absolutely nothing to do with the package activation time, but rather its load time 😛.
That can be moved to the first time things are using by moving to a lazy load model, for example how linter-stylelint is written here.
(Your earlier PR changed the package from automatically activating no matter what on Atom launch to only activating when a relevant language is used, the lazyRequire changes are the other half of the equation)
Well, atom's timecop definitely lists it as activation time. AFAICT this includes package load time since atom does not load the package until right before it is activated for the first time.
However you call it though, it will slow down the opening of the first JS editor by a good second.
Considering that many people will have files linted automatically, lazyRequire might not make that much of a difference.
Well, on second thought, waiting an additional second for the first linting results would definitely be preferable to delaying editor display.
Due to the PR you already sent in the package will only be activating when a relevant language is loaded. Moving the requires to a lazy method will defer loading the dependencies until a lint is actually requested. For people who are working on JS code it won't be too much of a difference (especially if Atom resumes a session to an open JS file), but others working on non-JS code it will help.
atom crashed when I open a large js file with linter enabled (i am working on macbook pro)
@sjy That has nothing to do with this issue...
From the sounds of it your problem is possibly that you just didn't wait long enough for things to finish processing. Ideally this package would run jscs in a separate thread that doesn't block the UI, but it doesn't work that way, and I have no interest in updating it to do so since the JSCS linter is dead.
You should look into moving to ESLint, especially as linter-eslint does do the hard linting work in a separate thread that doesn't block the UI.
Marking this as closed, JSCS development is dead, and it seems none of the people still using it are interested in implementing this functionality.