Cabbage Logo
Back to Cabbage Site

New profiler opcodes

#1

When working with very large orchestras, I’ve always missed the ability to quickly profile blocks of Csound code to test for bottlenecks. There are ways to do it using some of the timer opcodes, but that approach always felt a little cumbersome. Over the weekend I decided to throw together some utility opcodes that can be added to a .csd that will measure the average amount of time it takes to execute a blocks of code in microseconds (one millionth of a second).

Note: this is a very rudimentary way of profiling code - it only reports the time spent executing a block of code. While it can be useful in a ‘general direction’ sense, it tells us nothing about important things like call frequency or memory allocation…

cabbageProfilerStart Opcode

This opcode sets up a profiler with a unique name, and a corresponding code block label. The unique name can be passed around to other instances of each of the profiler opcodes.

Added in Cabbage v2.9.179

Syntax

cabbageProfilerStart SName, SBlock

Initialization

  • SName – the profiler name
  • SBlock – the profiler code block label

cabbageProfilerStop Opcode

This will stop the profiler and record the time spent on executing a block of code.

Added in Cabbage v2.9.179

Syntax

kTime cabbageProfilerStop SName, SBlock

Initialization

  • SName – the profiler name
  • SBlock – the profiler code block label

Performance

  • kTime – the amount of time in microseconds spent executing the block of code.

cabbageProfilerPrint Opcode

This will print the cumulative data from each of the profiling blocks. You need only call this opcode once per profiler, and it’s best to place in the last instrument of the processing chain.

Added in Cabbage v2.9.179

Syntax

cabbageProfilerPrint SName

Initialization

  • SName – the profiler name

Example

instr 1 
    ;create profile with label 'p1' and test block 'oscil'
    cabbageProfilerStart "P1", "oscil"
    a1 oscil 1, 100
    ;stop block 'oscil' test
    kTime1 cabbageProfilerStop "P1", "oscil"


    ;add a new block 'pvs'
    cabbageProfilerStart "P1", "pvs"
    ifftsize  = 1024
    ioverlap  = ifftsize / 4
    iwinsize  = ifftsize
    iwinshape = 1						
    ain       vco2 1, 1
    fftin     pvsanal ain, ifftsize, ioverlap, iwinsize, iwinshape
    fftblur   pvsblur fftin, 2, 4	
    aout      pvsynth fftblur					
    ;stop block 'oscil' test
    kTime2 cabbageProfilerStop "P1", "pvs"

endin
5 Likes
#2

Nice. In Csound, we would do this with ‘clockon’ and ‘clockoff’ opcodes, but… I was always a bit suspect of what they ‘really’ told me about the efficiency of my code. Is thee something that shows the CPU load of the plugin.

#3

It was only after I wrote these that I discovered the clockon/off opcode. I guess these are a little more accessible in so far as you can get a nice detailed report about each of the blocks efficiency, and it also reports the average time spent executing each block. Most DAWs have a CPU load meter for plugins. I know Reaper and live do. I usually use it to gauge the load of a plugin. And if I spot some crazy issues I would have typically opened the plugin using one of XCode’s time profiler instruments. But now I can do the same analysis using these opcodes. As I mentioned in the the original post, these are quite ‘general’ in terms of profiling, but it’s also good to know which blocks of code are taking the longest to execute. :slight_smile: