Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Performance issues with large repositories #152

Open
umphy opened this issue Apr 6, 2023 · 2 comments
Open

Performance issues with large repositories #152

umphy opened this issue Apr 6, 2023 · 2 comments
Labels
πŸ› bug Defect / Bug

Comments

@umphy
Copy link

umphy commented Apr 6, 2023

πŸ€” 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 kieran-ryan added the πŸ› bug Defect / Bug label Dec 3, 2023
@kieran-ryan kieran-ryan changed the title Working with large repositories is extremely slow. Working with large repositories is extremely slow Dec 30, 2023
@kieran-ryan
Copy link
Member

kieran-ryan commented Jan 1, 2024

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

@kieran-ryan kieran-ryan changed the title Working with large repositories is extremely slow Performance is poor with large repositories Jan 7, 2024
@pmthexton
Copy link

pmthexton commented Feb 17, 2024

@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.

@kieran-ryan kieran-ryan pinned this issue Mar 24, 2024
@kieran-ryan kieran-ryan changed the title Performance is poor with large repositories Performance issues with large repositories Mar 24, 2024
@kieran-ryan kieran-ryan unpinned this issue Jul 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
πŸ› bug Defect / Bug
Projects
None yet
Development

No branches or pull requests

3 participants