Very slow performance

[efagerberg]

I have noticed recently that this extension seems to run slower than before and eventually end up in an unresponsive state which is only resolved by restarting vscode.

• Issue Type: Bug
• Extension Name: vscode-coverage-gutters
• Extension Version: 2.6.0
• OS Version: Linux x64 5.8.0-43-generic
• VSCode version: 1.53.2

{
    "messages": [],
    "activationTimes": {
        "codeLoadingTime": 145,
        "activateCallTime": 5,
        "activateResolvedTime": 0,
        "activationReason": {
            "startup": true,
            "extensionId": {
                "value": "ryanluker.vscode-coverage-gutters",
                "_lower": "ryanluker.vscode-coverage-gutters"
            },
            "activationEvent": "*"
        }
    },
    "runtimeErrors": []
}

[efagerberg]

Closing, this was due to not ignoring my .tox dir.

[ryanluker]

@efagerberg Thanks for opening a ticket (this helps others that might also have slow performance due to not ignored folders). Do you have a directory that we can add to the current set of defaults to help avoid this in the future for others?

Currently we use this as the set of defaults **/{node_modules,venv,.venv,vendor}/**.

[efagerberg]

Thanks yeah .tox would be a good one too add

[ssbarnea]

I have an M1 machine and it takes 14s to display the gutters. The coverage.xml file is only 150kb. I added .tox to the ignore list and it took 2s to display the gutters. At this size I was hoping to be more like 0.2s so I suspect there are other operations

Now the tricky bit is that historically I almost always stick the coverage.xml file inside the .tox folder because that was another temp file and also produced while using one of the tox venvs anyway. I am sure that lots of users might do the same.

I do think that the root cause of the problem is the default ** search folder (Base Dir), which makes it too deep by default. I would say that for 99% of users the coverage files should at the first two levels, not deeper.

To make situation worse Base Dir and Coverage File Names cannot be configured at project level. For example go coverage extension allow you to configure them at folder level, and thus you can store their location in a git-tracked file. Workspace level does not help as a workspace is not expected to be tracked in git, as it is likely to contain multiple folders and other user specific preferences.

[ryanluker]

@ssbarnea Thanks for the added info!

A couple of thoughts:

1) Can you look into the debug logs and see how the performance is when using the watch mode? (you can access this area by going into the output tab and into the coverage-gutters dropdown).

In watch mode, the caching layer should kick in, and you should only have poor performance on that initial load of the coverages into the in memory cache.

2) Regarding the situation worse Base Dir and Coverage File Names cannot be configured at project level could you use these extension settings to adjust this for your needs? https://github.com/ryanluker/vscode-coverage-gutters/blob/master/package.json#L117-L137

3) I like the idea of searching within the first 2 levels to start and then using the full workspace / open folder as a fall back 🤔.

[Star9daisy]

Hi developers. I'm suffering from this problem recently or it becomes more serious these days. After looking at your discussion, it looks like the source of slow performance comes from the setting Coverage Base Dir.

Since my coverage report file is at the top level of the current workspace, I simply change it from ** to ./. Now without searching deeply the whole folder, your extension shows coverage blazingly fast.

[ryanluker]

Hi developers. I'm suffering from this problem recently or it becomes more serious these days. After looking at your discussion, it looks like the source of slow performance comes from the setting Coverage Base Dir.

Since my coverage report file is at the top level of the current workspace, I simply change it from ** to ./. Now without searching deeply the whole folder, your extension shows coverage blazingly fast.

@Star9daisy Thanks for this input! It might be useful to add that to the readme or a prominent place... 🤔.