Bad performance

[marcinjahn]

This issue is similar to https://github.com/Issafalcon/neotest-dotnet/issues/93. I have a solution with hundreds of test files. When I open any test file:

1. Running "nearest test" doesn't work initially
2. Opening Test Summary causes major slowdown of neovim. Moving a cursor becomes laggy, my laptop's fans start to spin pretty loud, and lots of dotnet processes get spawned.

The middle part is when test discovery got started.

After some time (a minute?) it cools down, and I am able to execute tests.

I have the following config (I'm using LazyVim):

return {
  "nvim-neotest/neotest",
  dependencies = {
    "nvim-neotest/neotest-jest",
    "Issafalcon/neotest-dotnet",
  },
  opts = {
    adapters = {
      ["neotest-jest"] = {
        jestCommand = "npm test --",
        jestConfigFile = "custom.jest.config.ts",
        -- env = { CI = true },
        cwd = function(path)
          return vim.fn.getcwd()
        end,
      },
      ["neotest-dotnet"] = {
        discovery_root = "solution",
      },
    },
  },
}

I'm using solution discovery_root, because I thought it could help. It didn't. I was unsure if it would actuall work, because in my repo I have two sln files in the same directory.

Is there anything I could provide to help with resolution of this issue?

[Issafalcon]

Hi @marcinjahn - Seems like you're right, the performance issue has reared it's head again for larger projects.

I believe I'd improved it by using a cache mechanism (see https://github.com/Issafalcon/neotest-dotnet/pull/94/files) to fetch the full test names, but this will need tweaking to ensure the cache isn't cleared as frequently, and probably to ensure a way for users to clear the cache themselves.

On the other hand, when I eventually get time (unlikely for a while though) I was going to look into VS Test and try to get the plugin functioning closer to test discovery and running does in things like visual studio, and rider. But this is a larger undertaking which would consolidate all the test runners.

[Issafalcon]

See #90 for the most robust solution to this