Console process (yarn install) runs slower then in native console

[wclr]

• VSCode Version: 1.6
• OS Version: Windows 10

Noticed that yarn install process takes longer time in vscode console. Think this should be investigated.

Can be reproduced this way:

1. install yarn package manager (npm i yarn -g)
2. create package.json and add two dependencies:

    "babel-preset-es2015": "^6.6.0",
    "babel-preset-stage-0": "^6.5.0"

3. run yarn in this directory.

Those modules have many internal dependencies and yarn install (Link dependencies state) takes quite a long time, so it can be compared running in native console and in vscode integrated terminal.

[rozzzly]

I suspect this has something to do with how yarn writes its the stdout buffer.

It's probably trying to make the console redraw each time it's little animated spinner changes frame ---> vscode uses js to emulate a terminal for your prefered shell (eg: bash) ---> console takes longer to draw/gets backed up ---> slow install ---> 😞

If my intuition is correct, it's not really a vscodeproblem (or more accurately one vscode can easily fix) so I think you'll find more help on the yarn repo than here...

Look to see if there is a way to disable the spinner with a cli flag (which you could alias and never have to deal with again). That's a simple fix, but I suspect the console-progress_updater and the do-the-downloads-and-stufff logic are running in the same even loop (the same thread so to speak) and keep bumping into each other causing it to be slow in vscode because vscode takes a bit longer to handle input than your standard, natively-compiled, terminal emulator.

[wclr]

@rozzzly I believe currenlty no way to to prevent progress bar with flags. So I think if it is possible vscode should fix this, I will create an issue in yarn if it is not here already.

[rozzzly]

@whitecolor should my hunch be correct, you're asking vscode to (potentially) totally rework it's integrated terminal. That's asking a bit much when they can add a CLI flag with less than a dozen lines of code. lol. Anyway, someone will have to some metrics/profiling, and hard thinking to see what's causing the issue you're experiencing. Do you get the same experience in atom or other editors/ide sublime/jetbrains/etc... ??

[wclr]

@rozzzly I just think that the issue should be investigated first. I didn't try in other IDEs, any way they all have crappy terminals (jetrans esp), VScode terminal seems to work much better in my experience.

[wclr]

Seem yarn soon will have this feature of disabling progress bar shipped yarnpkg/yarn#1190

[Tyriar]

Thanks for the report, I'm going to close this off in favor of xtermjs/xterm.js#318 (to properly support "spinners" or progress bars) and yarnpkg/yarn#1190.

[Tyriar]

Just to clarify, I'm not actually seeing any performance related problems with the integrated terminal, and I wouldn't expect to. I do however see broken progress bars which is related to the upstream issue xtermjs/xterm.js#318

Seeing the same in both 1.6.0 and 1.8.0-insiders.

[wclr]

@Tyriar try with for example those deps:

    "babel-preset-es2015": "^6.6.0",
    "babel-preset-stage-0": "^6.5.0"

They have many internal deps (about 90 000), you probably should see the difference.

Btw there is also problem in windows 10 that slows down the process in general yarnpkg/yarn#1496

[Tyriar]

That screenshot is installing those two, on Windows 10. It only took a few seconds as expected. Was your yarn cache not primed when you tried in the integrated terminal?

[Tyriar]

xtermjs/xterm.js#318 is actually the wrong issue, that's just related to selection which line updates are happening. The progress bar issue is in pty.js, I've enabled issues on the repo and made an upstream issue for it https://github.com/Tyriar/pty.js/issues/2

[wclr]

@Tyriar ah then I probably had more complex deps set and count while Linking dependencies was not 3 thousand but 90. So there definitely difference is seen.