Lately I’ve been finding that auto-reload is really slow. Looking into it, I realized it’s because I’ve installed Paketti, which is quite a monster of a tool. Renoise seems to rescan it every time I edit my own tool — even if I hack Paketti to remove _AUTO_RELOAD_DEBUG.
This scan unfortunately takes about 5 seconds on my machine, so disabling the tool is the only option. That is a poor solution because Renoise does not maintain my keybindings when I re-enable it.
Edit: After further experimentation, I think my hypothesis that this is a Renoise issue is likely mistaken. Clearing out the Paketti folder while Renoise is running doesn’t change anything. If anyone has any idea what could be going on, I’d like to know.
Edit 2: After bisecting Paketti’s codebase, and getting an insight from Esa, I’ve worked it out. Paketti is programmatically generating lots of keybindings. The number of loaded keybindings has a huge effect on auto-reload’s performance.
Below are two stress test tools. They respectively make 10,000 keybindings and 10,000 menu entries. If you install BindingStressTest and then auto-reload any tool, it should take a very long time—over 30 seconds on my system. On the other hand, MenuEntryStressTest does not seem to have an effect.
ok so i’ve done a few things: PakettieSpeakhotelsinus_stepseq and PakettiPTILoader all had _AUTO_RELOAD_DEBUG=true
i’ve removed them - so that was four_AUTO_RELOAD_DEBUG=true messages in a single tool.
the only place that has _AUTO_RELOAD_DEBUG=true now is main.lua. maybe that helps?
other than that (if this change doesn’t change the timeout period during reload), could it be a case of too many files?
Paketti has 5396 items.
i could make it so that main.lua actually gets injected a isItTrue=true → isItTrue=false tweak during GitHub action aka rolling the xrnx with _AUTO_RELOAD_DEBUG=isItTrue aka false - . but that won’t really solve your situation of having the Paketti GitHub repo in your Tools folder?
any advice/ideas would be cool. but not “split the tool”.
I think if it is a Paketti issue then it must be deeper than that, because disabling auto-reload doesn’t fix it, and even wiping the Paketti folder while running doesn’t fix it. So either it’s something that Paketti is doing which is persistent, or it is a Renoise issue (which I now think less likely, but not impossible).
Would it not better only reloading active used Pakette Tools? Maybe over a “active flag” which can be setup in config and/or over ToolMenu, or Tool init routine? That maybe gives some fluffiness.
Paketti includes all the code of the internet and of other tools. It registers a million of shortcuts for each pixel of the screen and each line of the pattern. Therefore it was clear from beginning that it will drastically slow down renoise, even though renoise got a lot faster with 3.5. tbh I would recommend not to use it. I also don’t think that you need these shortcuts either. It might be better to install individual, specialized tools which you really need, instead. But this is just my personal point of view.
Well, that’s a fair enough assessment, but Paketti has some nice and original features as well, including some I’ve helped to implement. Its size is never much of an issue for me except in this very particular case.
Wouldn’t it make more sense to remove this Auto Reload flag completely and have it as a checkbox in the Renoise Tool Browser instead? Stuff like debug flags doesn’t really belong in the final code of a release version, right? At least I always tried to avoid that in my own stuff.
The debug flag doesn’t do anything unless you edit the code, so it’s not hurting anything. When I made this post, I thought maybe it was malfunctioning and reloading other tools, but I realized this was a mistake.
Also, _AUTO_RELOAD_DEBUG can be bound to a function, so it doesn’t really make sense as a checkbox.
Sorry to bump this, I just wanted to make it clear that this isn’t about any specific tool. It’s about Renoise’s keybinding mechanism scaling poorly. I think the fact that one tool can have an outsized impact on other unrelated tools (even if only from a developer’s perspective) ought to be considered a bug.
I’ve done some rough profiling using Activity Monitor and during the hangs, Renoise spends most of its time in TRenoiseApp::OnRegisterAndValidateKeyBindings.
