Repository navigation
require('sass.js') slows down TS Server #19458
Description
TypeScript Version: 2.6.1-insiders
Code
In a new project
npm i sass.js
With an index.js file:
require('sass.js')Trigger intellisense in the file
Expected behavior:
Should return suggestions pretty quickly.
Actual behavior:
Delay of a few second before suggestions are returned
Activity
mjbvz commentedon Oct 24, 2017
Here's a tsserver log of this:
The bug seems to be triggered even if I create a
jsconfig.jsonto exclude node_modules:mjbvz commentedon Oct 24, 2017
The problem does appear to be
./node_modules/sass.js/dist/sass.sync.jswhich contains some minified code. I also confirmed the same issue exists in TS 2.5 and 2.4mhegazy commentedon Oct 24, 2017
I am not seeing this locally.. i see a slight delay on the first completion, which is something i expect since the file is 3 MBs and we need to parse it. but after that completions almost instantaneously.. am i missing something in my setup?
from the log above, i see the time between open command and getting a completion command response is less than 1 sec.
mjbvz commentedon Oct 24, 2017
Hmm, not sure. Pine (@octref) and I have been able to reproduce it pretty reliably on mac using TS 2.6.1-20171019-insiders. I was using npm 5 and he was on yarn but I'm not sure if that makes any difference
I'm also not sure the full delay shows up in the tsserver log. Here's what I see for VS Code's communication with the TSServer for example:
The tsserver log for this same event:
mhegazy commentedon Oct 24, 2017
I see a 2 sec delay on my machine on the first completion, but later ones seem to be fine:
do you see the same?
mjbvz commentedon Oct 25, 2017
I sometimes see a much larger delay whenever triggering completions:
That was in a new project with only
sass.jsinstalled and anindex.jsfile. The completions request itself does not seem to be causing the delay itself, rather it just seems to trigger itmhegazy commentedon Oct 25, 2017
The first time the delay is in parsing/binding the file. locally it takes somewhere between 2-4 seconds. once that has happened things should be fast. that is not different from a large project, where building the project takes a few seconds, then things should all be in memory.
do you see delays in later completions requests after the first one?
octref commentedon Oct 25, 2017
Mohamed Hegazy (@mhegazy) #19459 (comment)
mjbvz commentedon Oct 25, 2017
I still see a significant delay for each subsequent completions request after I edit the file. Looking at the logs again, this delay seems to come when we invoke
geterr:The delay seems to happen between
Finishing updateGraphWorkerat (11:3:3.501) and the event forsemanticDiagat (11:3:10.864). At this point, VS Code has already issues acompletionEntryDetailsrequest against the TS Server which has been queuedmhegazy commentedon Oct 26, 2017
tested this side by side with Matt Bierner (@mjbvz) and there is definitely something going on mac's that is not happening on windows boxes. need to investigate further on a mac.
5 remaining items
sheetalkamat commentedon May 8, 2018
Messaged Matt Bierner (@mjbvz) offline about the microsoft/vscode#49251 not fixing the issue and detailed logs.
sheetalkamat commentedon May 15, 2018
Investigating this with latest code-insiders still repros the issue but the issue now lies with us since we spend time in parsing the sass.async file
This is what I did:
in index.js typed require("sass.js") and waited till all the diagnostics are reported.
After this I completely deleted the line and typed it again followed by new line and completion list invoke. At this point I see long wait for the completion just like you will see right after opening index.js(and not waiting for initial refresh)
The cause of this is that, even though the script info for sass.async.js is in memory, its source file that's registered in the documentRegistery is released as soon as it gets removed from all projects, resulting in not being able to reuse the source file. If we can keep source file alive, that will help with the faster program creation. But interesting to note is that sourceFiles document registry is dependent on the compiler options so its not as simple and we need to handle cases when document is part of multiple projects etc well.
sheetalkamat commentedon May 15, 2018
Used branch programInServerPerfLogging to investigate this
Add noGetErrOnBackgroundUpdate session option to not queue diagnostic…
Add noGetErrOnBackgroundUpdate session option to not queue diagnostic…
Make suggestion diagnostics to wire cancellationToken