Does bypassing / disabling modules save performance?

I tried to make a patch where I can select between different modules using Stoermelders STRIP for fast module switching that I can control via Midi CC, but I noticed that as the number of disabled modules grew, the performance decreased. By performance, I mean the number of XRUN’s thrown by Jack, and the amount of ‘clipping’ noises.

So I was wondering if disabling modules removes their cpu overhead? I thought that they did at first but I’m not sure now.

Yes, a disabled module does not process any DSP and does not consume any CPU cycles for processing. It still consumes GPU as the module must be rendered on your screen.
That been said I’ve seen modules misbehaving when disabled and consuming even more CPU.

Is it possible for a module to tell another to disable/enable? I.e. assuming you have a large multi-instrument patch, could you select parts to be enabled/disabled from a controller generated trigger?

In that case I think my modules are misbehaving, because once I delete all the disabled modules the performance goes back to normal.

I also confirm that disabling a module makes it consume nearly zero DSP time. But I’ve never seen a module take more CPU when disabled. Open a bug report if you can find a reproducible example.

In Rack v2, the “disable” feature will be renamed to “bypass”, and Module::processBypass() will be called instead of process() so theoretically a module could do more work in the bypass method although this will be rare in practice.

You’re right, I should do that. I think it was one of the Nysthi modules which uses a worker thread for FFT or something…

Ah, that makes sense. Code like

loop:
    if module is ready:
        processFFT()
    yield()

would enter a yield loop which might use more CPU than simply processing the FFTs. Better to use signals/mutexes.