How to profile my module – for a beginner

epadilla · November 16, 2023, 3:59am

Hi there, I’m working on a new module and have noticed that CPU usage is kinda high. I’d like to make it more efficient but want to where I should focus my efforts so I want to do some profiling on my code.

However, I am not very experienced in profiling and have not been able to find good resources for how to do it for Rack plugins. Does anyone have tips or pointers for how to get starter profiling my module? Is there a preferred tool? I currently build my plugin with the Rack SDK and make install it and just run my downloaded Rack app. Would I be profiling all of Rack? Is there a way to profile my module specifically?

For context, I am developing on an M1 Mac (building for x86).

Thanks!

Squinky · November 16, 2023, 4:26am

rack plugins are so simple that you shouldn’t need to use a profiler. Just take stuff out of your process function and see what effect it has. And of course read my ancient paper https://github.com/squinkylabs/Demo/blob/main/docs/efficient-plugins.md.

fwiw, I’ve never run a profiler in rack.

LarsBjerregaard · November 16, 2023, 6:34am

epadilla · November 16, 2023, 7:02pm

Oh interesting, I was for sure assuming that developers like you would be profiling their modules. Thanks for the link, I will use that to rethink some of the likely culprits in my code.

epadilla · November 16, 2023, 7:04pm

Thanks, I have read through this page. Unfortunately I think I need something a little more verbose that explains how to set it up.

baconpaul · November 17, 2023, 12:02am

Whats your os? I have had good luck with the dtrace profilers built into macos and linux and the wrappers around them in CLion and instruments (instruments is macos only).

If you are windows I have no help for you though!

Also I agree with squinky yu can get pretty far by knocking out blocks and doing timeit on blocks. I would say that, the peek at the assembly, the run the profiler in order is what I usually do

Squinky · November 17, 2023, 1:28am

yeah, I run on windows, and sometimes in Linux. I don’t really want to learn how to use a new profiler, so I never have. As in never, ever, not once. I have run other tools on my modules, but never a profiler.

The documents that @LarsBjerregaard pointed you to are for sure good and correct. In general, anyway. In general it’s true you have no idea where the bottleneck is, and it’s never where you might guess.

But a VCV module is not “general”. It’s not a big program like VCV where you need a profiler. You know exactly where the bottleneck is - it’s in your process function! By definition.

If your process function is longer than 100 lines you are doing something wrong. It’s either obvious where the problems is (if you have a lot of experience), or it’s easy to find it. Like I say, if you have no idea just remove half the code. It won’t take very long to get to the very line that’s the problem.

You don’t need any special tools to do this.

Squinky · November 17, 2023, 6:00am

also, this article on using the CPU meters is perhaps low-tech, but it works:

github.com

squinkylabs/Demo/blob/main/docs/cpu-meters.md

# Using VCV CPU meters

This document began as a forum post on the VCV Community forum. But it was pretty popular, so I'm putting a copy here.

I’m going to show how I compare/test two plugins. I’m sure others have their own way, I’m sure there are plenty of good ways.

First of all, I arbitrarily picked two VCOs, One from Bogaudio, one from VCV. I could have picked other ones, but I picked these ones because the are reasonably comparable, I know they are both very good, and I have used them a lot.

I set VCV for one thread, real-time priority. I tested three “patches” monophonic with no modulation, 4 voice polyphony and no modulation, and then monophonic with lost of modulation. This will tend to hit the performance areas I’m interested in, a) how does the cpu usage change with polyphony, and b) does performance get terrible with lots of modulation.

With simple, well-designed modules like these, the number are too small to compare, so if the CPU usage is really low I set the engine sample rate to X 16, which is what I did here. This will usually make the CPU use increase by that much and make the numbers easier to read.

I use more than one instance to the module, as I can average them to get a more accurate read. Also it’s easy to see if the meters a giving an inaccurate reading on one. Usually I’m not trying to get a super accurate reading, so I can tell by looking how they compare. Sometimes I’ll just ignore the highest reading from both A and B.

Here are my results with one voice and no modulation:

![Mono patch with no modulation](./cpu-mono-no-mod.png)

Remember, these are very small numbers, and I had to artificially boost them 16X just to see them. Looking at these results my takeaway is that the CPU usage of both is very low. I’m sure one could easily find comparable modules that are much, much higher. Also, if it’s really a competition, the Bogaudio looks like it is 4X more efficient is this specific case.

This file has been truncated. show original