I've been roughly measuring the performance of pd's audio atoms by creating large arrays of them in a subpatch and monitoring overall CPU usage. I'll post the measurement patch if there's demand.

bob~ 168.00
vline~ 80.00
bonk~ 50.00
sigmund~ 43.00
line~ 21.50
pow~ 19.25
mtof~ 14.50
exp~ 10.50
vcf~ 8.25
log~ 7.00
framp~ 7.00
sqrt~ 5.50
q8_sqrt~ 5.50
rsqrt~ 5.25
q8_rsqrt~ 5.25
rfft~ 5.00
tabread4~ 5.00
osc~ 3.50
cos~ 3.50
bp~ 3.50
tabread~ 2.50
rpole~ 2.25
lop~ 2.22
phasor~ 2.00
tabosc4~ 2.00
/~ 1.67
ftom~ 1.63
rzero~ 1.25
abs~ 1.06
clip~ 1.00
threshold~ 1.00
vsnapshot~ 1.00
tabwrite~ 0.88
hip~ 0.72
+~ 0.61
*~ 0.61
-~ 0.61
snapshot~ 0.50

@cult Wow..... a lot of useful work.... thank you for posting!
I don't think audio is the main culprit for intense cpu usage....... https://puredata.info/docs/old/FAQ/HowCanIOptimizeMyPatches/

I run a patch regularly that mixes 32 [adc~] to 20 [dac~] with 4 band eq on every in and out, reverb etc.,and it runs wav playback at the same time, on one half of one processor (32-bit). The DSP hovers around 14-16%. Once the audio chain is built at start-up into a combined chain the individual objects have much less relevance, although it is well known that [x~ 0.5] is more efficient than [/~ 2].

I don't think that a big array of audio objects is at all the same thing as those same objects all linked in a chain....... but that might be worth investigating.

It is the control data, including a ton of osc messages, that hog cpu, but less so if data is not written to the screen. -nogui is an option sometimes.

There is a bit of interesting reading here though...
http://www.pdpatchrepo.info/hurleur/multiprocessing.pdf

4 point interpolation, re-sampling, lots of control data ( [line~] and especially [vline~] ) are hungry..... as you have found...
David.

@whale-av Thanks for those links, that's interesting stuff.

Audio can be responsible for maxing your CPU if you do daft things like massively parallel saturation with bob~s on an old raspberry pi.

You're right, pd does indeed optimise away unconnected audio atoms, so my arrays are fully connected in one big chain like this:

I'm fairly convinced my methodology is sound enough that these results will reflect how various atoms contribute to the CPU use of a patch in practice. There may be some clever atoms that deactivate if they detect zero audio, but I've not noticed any behaviour like that. There are also effects like pipelining, caching etc. I'm assuming they won't be huge factors.

I have yet to look at expr~ and vexpr~, they'll take a bit more work to analyse.

[sigmund~] should show different results depending on whether you are outputting a pitch estimate or decomposing the signal into tracks.