Vscode: Build task starting has slowed down

[BillDenton]

• VSCode Version: Code 1.15.0 (8b95971d8cccd3afd86b35d4a0e098c189294ff2, 2017-08-09T20:16:18.034Z)
• OS Version: Windows_NT x64 6.1.7601
• Extensions:

Extension|Author (truncated)|Version
---|---|---
language-x86-64-assembly|13x|2.2.11
rainbow-brackets|2gu|0.0.6
read-only-indicator|ale|0.6.0
alignment|ann|0.3.0
Doxygen|bbe|1.0.0
python|don|0.7.0
matlab|Gim|0.6.0
triggertaskonsave|Gru|0.1.3
vscode-dimmer|hoo|2.1.0
select-part-of-word|mle|1.0.1
cpptools|ms-|0.12.2
PowerShell|ms-|1.4.1
indent-rainbow|ode|0.6.1
vscode-clearcase|Ope|1.10.0
vscode-icons|rob|7.12.0
indenticator|Sir|0.4.2
vscode-hexdump|sle|1.4.0
code-spell-checker|str|1.3.6
comment-snippets|Tob|0.2.0
selectline-statusbar|tom|0.0.2
change-case|wma|1.0.0
highlight-trailing-white-spaces|yba|0.0.2

(1 theme extensions excluded)

---

Steps to Reproduce:

1. Configure a build task in tasks.json:
   "group": {
   "kind": "build",
   "isDefault": true
   },
2. Start that task by pressing Ctrl+Shift+B
3. "Fetching build tasks" appears on status bar. This stays there for a few seconds. This message didn't appear on the previous release and the start of the build task appeared to be faster.

Reproduces without extensions: Yes/No: Not check yet.

[BillDenton]

I have now disabled the auto-detection of tasks and usable again. So I think the problem is that it is taking a long time looking for auto-detected tasks. The auto-detected tasks are no use to me. I suggest that it could do the task detection in the background whilst allowing access to the pre-configured tasks. This could make it faster.

[dbaeumer]

Our ideas to improve this is two folded:

• allow enabling and disabling of task providers in the tasks.json. If disabled and it is a customized task only resolve the customized task and not auto detect all tasks
• if a task is trigger explicitly (e.g. via Run Build Task) and it is a task fully defined in tasks.json execute the task without auto detection (this is what you suggest as well)

[hortegilles]

how do you disable auto-detected tasks ?
it s a configuration into user settings ?

[BillDenton]

It is in user settings. Search for autoDetect and set them all to "off":
"typescript.tsc.autoDetect": "off",
"grunt.autoDetect": "off",
"jake.autoDetect": "off",
"gulp.autoDetect": "off",
"npm.autoDetect": "off",

[draeger-charles-wilson]

The slow task behavior is present in 1.18. I have a project of 30k files.

I was seeing 2+ min to bring up the run task for the simple sample task mentioned in the documentation. Then it was another 2+ min with no feedback until the task ran.

Once I turned off all the auto-detection, as mentioned above, the response and run time was nearly immediate.

Can the above settings be made the default?
Can the above be included in the task documentation?

[dbaeumer]

Added this to the documentation.

@draeger-charles-wilson which kind of task runner are you using?

[draeger-charles-wilson]

Vanilla.

{
    // See https://go.microsoft.com/fwlink/?LinkId=733558
    // for the documentation about the tasks.json format
    "version": "2.0.0",
    "tasks": [
        {
            "label": "echo",
            "type": "shell",
            "command": "echo Hello",
            "problemMatcher": []
        }
    ]
}

[dbaeumer]

I mean do you have gulp, jake, grunt, package.json files in that workspace ?

[draeger-charles-wilson]

None of the above are present.

[dbaeumer]

How does the list of task look like for you ?

[draeger-charles-wilson]

Run Task... appears as follows:

I've added a second task.

[cobrabr]

I'm having the same problem but even turning all the auto-detection off doesn't solve it. Also, it's pretty random whether it will be slow or not -- sometimes it's almost immediate, but most times it actually times out without showing any tasks whatsoever.

EDIT: it seems it has something to do with one or more of the extensions I have installed. It might help other people having the same issue to try and run code with --disable-extensions and test if the slowness persists.

[dbaeumer]

@cobrabr thanks for the information. Where you able to pin point the extension that causes this?

[BobFrankston]

I'm running into this slowdown. It happened after upgrading to 1.2. Can talk a number of minutes even after it stops saying "searching for build tasks". I can take more than ten minutes before I see

[11:34:40 PM] Starting compilation in watch mode...
[11:34:42 PM] Found 0 errors. Watching for file changes.

I checked the clock and gave ctrl-shift-B at 11:22

[dbaeumer]

@BobFrankston can you reproduce this if you disable all extensions (e.g. start with --disable-extensions)

[BobFrankston]

Solved! It's a video server application and I had a subdirectory with junctions (links) to large libraries. Apparently, typescript searches in all the trees before it starts.

There isn't necessarily a fix as such but perhaps typescript could say what it's busy doing -- namely searching the file tree.

There is, however, a related bug in being unable to handle loops created in import (or worse). But that's part of the larger issue of very poor (OK, zilch) support for reparse points. This problem is exacerbated with OneDrive having its own approach with documentation I have yet to find.

[dbaeumer]

Great to hear that you were able to track it down. I agree on the progress suggestion.

[tw1nk]

It would be nice to have a global setting to disable all task auto detection. I manage my tasks.json manually and don't want to use the auto detection. I usually have projects open with more than 50k files. (this is including a build folder) and with those project sizes the auto detection is just too slow.

[dbaeumer]

Fair. I created https://github.com/Microsoft/vscode/issues/63841

[ericnewton76]

Yeah I'm seeing the same drastic slowdowns, and my file structure (minus bower_components and node_modules) is not that much:

$ find . -type f | wc -l
31252
$ find . -type f -not -path "./.git/*" -not -path "**/bower_components/*" -not -path "**/node_modules/*" | wc -l
413

A different project I have, it runs fast:

$ find . -type f | wc -l
44
$ find . -type f -not -path "./.git/*" -not -path "**/bower_components/*" -not -path "**/node_modules/*" | wc -l
7

is it having to search through all 32k files, just to list tasks? thats a greedy algorithm approach that should probably be re-evaluated... like have a convention based approach initially with a more comprehensive approach if user specifies.

convention based would be ignoring common file-based structures like .git, node_modules, bower_components, etc, to search for gulpfile, (whatever grunt's normal file is), etc

The global setting for ignoring task providers is an okay workaround for this, but the real diagnosis should be the task providers being too greedy.

A best case scenario is use the convention approach first, display those tasks found easily. Async run a more comprehensive to fill in the gaps, while that Task List dropdown is presented to the user, with a visual indication that its still looking.

[dbaeumer]

@ericnewton76 your case is different and was caused by a problem in TypeScript task provider. It is fixed for the next stable release.

[alexr00]

We can tell how long a single provider takes. It would make sense to add a notification for any long providers suggesting that you might want to disable them.

[alexr00]

Code pointer https://github.com/Microsoft/vscode/blob/master/src/vs/workbench/contrib/tasks/browser/abstractTaskService.ts#L1253

[joelspadin]

I would also find it very helpful to have something like Developer: Show Running Extensions that shows how long each provider took, so as a developer you don't have to add your own profiling code, and as a user you can see how each provider is affecting your workspace.