[BUG] neotest adds 3 seconds of startup time to neovim

[wjakob]

NeoVim Version

NVIM v0.10.0-dev
Build type: RelWithDebInfo
LuaJIT 2.1.0-beta3
Run "nvim -V1 -v" for more info

Describe the bug
nvim takes a long time to start. Instead of the usual barely noticeable <200msec delay, it takes around 3 seconds on one of the machine I use for development. Further investigation reveals essentially all of this time to be spent inside of the neotest initialization. The issue is platform-specific and happens on an idle Linux server (AMD Threadripper 3990X running Ubuntu 20.04.6 LTS) but not on my main development machine (Apple M1 laptop). I am wondering if it could be some parallelization step having difficulty with the large number of virtualized cores on this machine (128 with hyper-threading enabled). Though it is unclear in that case why parallelization would be needed just to start the plugin.

To Reproduce

Steps to reproduce the behavior:

1. Simply start VIM using nvim --clean -u minimal.lua (see below).
2. Experience the lag
3. :Lazy can be used to quantify the delay. See the screenshot below

Here is a minimal init.lua

local lazypath = vim.fn.stdpath 'data' .. '/lazy/lazy.nvim'
if not vim.loop.fs_stat(lazypath) then
  vim.fn.system {
    'git',
    'clone',
    '--filter=blob:none',
    'https://github.com/folke/lazy.nvim.git',
    '--branch=stable', -- latest stable release
    lazypath,
  }
end
vim.opt.rtp:prepend(lazypath)

require("lazy").setup({
  {
    "nvim-neotest/neotest",
    dependencies = {
      "nvim-lua/plenary.nvim",
      "antoinemadec/FixCursorHold.nvim",
      'nvim-neotest/neotest-python'
    },
    opts = { }
  },
}, {})

(Edit: the screenshot also shows nvim-treesitter, FixCursorHold and neotest-python which I removed from the minimal reproducer since they weren't actually needed to reproduce the issue.)

Logs

1. Wipe the neotest.log file in stdpath("log") or stdpath("data").
2. Set log_level = vim.log.levels.DEBUG in your neotest setup config.
3. Reproduce the issue.
4. Provide the new logs.

Done, the logfile is here: neotest.log

Additional context
It is completely unclear to me what it is doing during all of this time. I am not actually using neotest (yet), it is just the module initialization that is being slow.

[GopherJ]

why is this issue closed while it's still not fixed?