Looking to increase performance in VCV on my 2018 i5 MacBook Pro, are there any other ways to improve performance and reduce cpu load besides setting the threads to one and lowering the framerate? I also have a lot of modules installed, does that affect the load normally?
lots of modules on my system make just the modules window slower to load up, do not take more cpu.
there are light modules and heavy modules…try to find out the light ones, I can’t say much more…
1 Like
On old computer, in the view menu, I have set the light bloom parameter to 0%. I hope it’s lighter for this cheap graphic card
2 Likes
There are so many variables for CPU usage that it’s best to diagnose on a case-by-case basis. If a patch is glitching/stuttering, press F3 to toggle the CPU meter. Every module’s percentage adds up (sort of, depending on number of cores running, etc), plus small overhead of running Rack itself. You will get a feel for which modules need more CPU than others.
My performance tips. I really should create a seperate topic with them, then people can also add their own.
Heck, I’ll just duplicate them here for now:
Ok, so here goes - Lars’ explanation of Rack performance, and how to make the most of it, with most important things on top, and please do also read what the manual says about it:
- Only run as many threads as you absolutely need. So in the Engine->Threads menu you start with 1 thread. Only when your audio starts crackling you add 1 more thread, etc. and only after also applying the below performance tips. The reason is that adding more threads is NOT free!. Each additional thread added consumes some CPU because of thread scheduling overhead, sometimes a lot more, so always start with 1. In my own patches, on my own machine (an 2013 Core-i7 iMac), I never go above 1 thread, because by the time I get to adding another one the machine is already unpleasant to use, plus I never make monster patches.
- Have a decent graphics (GPU) card. Doesn’t have to be fancy just “discrete” meaning “not the inbuilt Intel graphics” (or AMD) in your CPU. The reason is, that if the GPU cannot cope with the load of rendering the graphics, the CPU takes over that duty, and so you end up burning a lot of CPU for just rendering graphics. The card has to be external to your CPU, so like the manual says:
* Graphics: Dedicated Nvidia/AMD graphics card from 2013 or later with recent driver update
* Integrated (non-dedicated) graphics such as Intel HD are not recommended and may cause significantly increased CPU usage.
- Run with as high a block size as you can in the audio module. If you are using external MIDI sources, e.g. a MIDI keyboard, and you need snappy/responsive/low latency, then gradually lower the blocksize until the latency is acceptable, but no more. The reason is that the lower the blocksize the more CPU is used.
- In the audio module, run with a sample rate of 44 or 48KHz. Only higher if you have a really good reason to. The reason is that the higher the sample rate the more CPU is used.
- In the Engine->Sample rate menu, run with the same sample rate as the audio module, always, unless you have a really good reason not to. It should usually be the “Auto” setting in that menu I believe, where auto means “same as audio module”. The reason is that if you don’t run the Rack engine and the audio module at the same sample rate, you will burn a lot of CPU re-sampling everything needlessly.
- Use CPU efficient modules. This is one of @Squinky’s pet peeves but also mine. There is a lot of variance between modules in CPU consumption, even if the modules otherwise look the same, with the same amount of functionality etc. It’s got everything to do with how well they are coded. There can be 10 x or a lot more variance in CPU consumption between otherwise identical modules. So put it to the test. When you’re deciding “which LFO should I use?”, put the 3-4 candidates next to each other, patch them up so they’re working, also very much with respect to whether you’ll be using them mono or polyphonically, hit F3 so you can see the CPU usage of each one and then decide. Using efficient or inefficient modules in your patch, especially big patches, has an awfully big consequence on the CPU usage of that patch.
- In the View->Frame rate menu, lower the graphics framerate if the machine is struggling. That can save quite a bit of CPU as well.
- Minimize the Rack window when you can. If you’re in a place in your workflow, where you’ve hooked up a recorder, and the patch is playing by itself, or you’re jamming on your MIDI keyboard, minimize the window. That will moderately, or sometimes dramatically lower the CPU usage. The reason is (I think) that, depending on graphics drivers, OS, etc. the GPU and CPU doesn’t have to do any drawing of graphics when the window is invisible, and drawing Rack and all the modules and graphics does take a toll on both GPU and CPU, so you’ll be saving cooling/heat/fan-noise plus some/a-lot of CPU.
- Have the Engine->Performance meters (F3) off when you’re not actively using it, because that uses some CPU as well.
That’s everything I could think of that’s accumulated over the years. There’s probably a couple of things I’ve forgot, but it’s going to be a while before I’ll bother to write that up again (again again), so now it’s up to y’all to point to this post when people are wondering about performance 
4 Likes
And so it was done…
2 Likes
I just read your post about performance, it’s really brought to light my MacBook is at a disadvantage compared to my other pc… but at least my next upgrade will help get going to Apple silicon and boost overall performance later…
1 Like
Going to an Apple Silicon computer will most likely feel like a massive boost compared to your 2018 Intel MBP.
I did get an ROG Ally from last year so it’s another step up, but I would imagine the apple silicon as three steps forward