Performance issues with large repositories

[umphy]

🤔 What's the problem you're trying to solve?

Working with a large repository is extremely slow, often making VS Code hang. Also, on restarting VS Code it seems like the extension needs to re-find/cache the feature/step files.

✨ What's your proposed solution?

Perhaps a persistent cache can be used so that the indexing/caching process is done only once, unless there is a change to files/directories.

Also, if possible that process should be a separate thread so it doesn't make VS Code unresponsive.

[kieran-ryan]

The extension performs a complete reindex on every workspace change to glob paths specified in settings, rather than reindexing the specific files changed; which is the cause of the performance issue. Resolving may require the implementation of a caching mechanism in the underlying Language Service and/or listening for 'onChange' events after the first index. PRs are welcome, feel free to take a look - any help towards resolution would be much appreciated.

c.c. @somecho

[pmthexton]

@umphy I've been running in to this as well. I don't consider the Cucumber project I'm working in to be particularly large (cucumber-ruby, 165 step defs, 15 parameter types, spanning across 17 glue files)

At first the language server, while parsing the Gherkin files very quickly, was taking around 3-4 seconds to scan the glue files for parameters/step defs... After some judicious re-arrangement of my folder structure and being very explicit with the cucumber extension glue globs list, I've gotten that down to 1-2 seconds, however, this does still result in VSCode "locking up" on me while those 1-2 second waits are occurring.

I feel like the issue is that there are a lot of await calls going on in the extension, rather than letting promises be promises.

I've found a solution that works for me though, and that's to use the experimental extension affinity option in VSCode. Add this to your workspace (or global I guess) vscode settings.json

    "extensions.experimental.affinity": {
        "cucumberopen.cucumber-official": 1
    },

This will run the cucumber plugin in a separate extension host process. Note that if you're using the Vim plugin, you can change the Vim plugin to be in a separate host process instead to also avoid locking up the UI... Do not configure both cucumber extension and vim extensions in affinity though, as the problem resurfaces, I'm presuming this to mean that "separate host process" in this case means literally a second process, rather than launching a process per extension configured for the affinity feature.