-
Notifications
You must be signed in to change notification settings - Fork 10
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
Diagnosing slow api.make.build() performance #126
Comments
Copied from discussion
|
@gwerbin, I find the issues interface a bit better for this as discussions starts hiding posts when things get long. In addition to pulling the latest head for the maybe useful report, I you could try adding a print statement after this: hotpot.nvim/fnl/hotpot/api/make.fnl Line 47 in bedc290
to get a real view on what files hotpot is looking at, in case its running amok somehow. You should be able to just open that file up in your repo, add the print and save, then hotpot should automatically recompile (you should see a report down the bottom if it worked), then open a new nvim instance to try it out. |
@rktjmp as I mentioned in the discussion thread, I ended up fixing my particular issue. That said, I think there's a case to be made for additional verbose logging of all files scanned (not just files compiled), so consider this a feature request. Could be useful in general when debugging a bundle of I pulled the main branch and the timing report looks great, thanks for adding that! I'm happy to help with improving logging. How do you feel about a |
Discussed in #124
Originally posted by gwerbin December 24, 2023
I recently cleaned out my config and switched from Packer to Paq. When I did so, I noticed a dramatic slowdown in execution time of
api.make.build()
, increasing from about 1 second to as high as 10 seconds. This occurs upon every run, not just the initial run. I used to use it as aBufWritePost
autocmd, but I've had to disable that since it's too slow.I made sure to clear out all old state, shada, etc. data before making the switchover, just in case it was causing the problem somehow.
I do not have
vim.loader
enabled; it caused a bunch of things to break when I turned it on. But I never needed it before now either, and this doesn't seem to be related to loading modules, because it happens on every run, not just the first run.require("hotpot")
itself is instant.I tried running with
set verbose=9
, but the only commands that run before the lag are twochdir()
s. I inserted aprint()
in the_get_lua_module_path
function to see if I'd somehow introduced a loop there, but I get exactly one file printed followed by the long delay.Even with the autocmd disabled, both the
HotpotCheckNvimConfig
andHotpotCompileNvimConfig
commands take several seconds, even when no files are modified.Therefore I suspect that somehow Hotpot has started scanning a huge number of files compared to before, but I'm stuck on where to go from here, aside from flinging some
print()
s in the source code to see what happens.Any help diagnosing this would be appreciated!
Here's my full config, in
${XDG_CONFIG_HOME}/nvim/plugin/plugin-config/hotpot.lua
:plugin/plugin-config/hotpot.lua
And here's a full list of files with the
.fnl
extension in the Nvim config prefix, which I imagined should be near-instant to process, given that most of them I have not changed:find ~/.config/nvim -name '*.fnl'
Neovim version:
Hotpot version:
The text was updated successfully, but these errors were encountered: