Not sure if this should be its own topic - but I also felt that it might be off-topic as a comment. I followed the interesting discussion/posts and inspiring patches in https://forum.pdpatchrepo.info/topic/14556/recursive-count-up-down yesterday. In the solution by @seb-harmonik.ar I was surprised by the [pd nop] usage since I would probably have used [t f] in cases where I want to visually structure or bundle float connections (this might also be a misunderstanding on my side in this case btw).

On second thought, I assumed that the former option might be faster though since it's just a "prolonged" connection through inlet->outlet and doesn't need to check types or so like [trigger] might possibly do (I didn't check Pd's code here - which I would most likely not understand - and this is probably also a rather naive technical perspective).

I sometimes test the performance of control rate solutions in my own patches with a little abstraction I created for this purpose: perf_meter.pd (this just repeatedly bangs a patch branch for 1s and counts the bangs) ... so I tried to compare the two with a simple counter - and to my surprise, the trigger seems to be faster (very slightly - but I get results like this repeatedly):

Now there are several questions:

• does my [perf_meter] abstraction make sense at all?
• if so - is there an easy explanation to this?
• did I understand the purpose of your [pd nop]s at all, @seb-harmonik.ar?

tbh I never measured, I think I just use [pd nop] for clarity. (zexy has a [nop] abstraction too)

I guess it makes sense for the [trigger] to be slightly faster than those different outlet indirections.

Imo there should be a [nop] built in

What's the advantage of that over a well-named send/receive?

using sends/receives seems like it's also more performant than the [nop] but less than the [t f]
For some reason I had been under the impression that it needed to lookup into the symbol table but that doesn't make sense.. it already knows the symbol

Thanks for your responses! now that's interesting about the s/r performance - in this case, i get the following results (repeatedly tested again):

[perf_meter]: pd_nop
    bangs  time(ms)  bangs/ms
  9603563    1000.0   9603.55
 
[perf_meter]: t_f
    bangs  time(ms)  bangs/ms
  9987069    1000.0   9987.06
 
[perf_meter]: send_receive
    bangs  time(ms)  bangs/ms
 10147908    1000.0  10147.90
 
[perf_meter]: connected
    bangs  time(ms)  bangs/ms
 10711894    1000.0  10711.88

Here's the patch if you want to check these on your side: test-performance-nop.pd

I updated perf_meter.pd with this additional newline for clarity - but as I said, I'm also not completely sure if this is a valid way of checking performance.

So why is [pd nop] the slowest? What is it about going through an [inlet] and [outlet] of a subpatch that slows it down? [t f] being slower than [send]/[receive] makes sense since [t f] would check the type to see if it needs to do conversion? I am guessing [send]/[receive] is slower than a connection because it checks the symbols once before the chain is executed and after that it is the same as a wire?

I think it's as simple as pd having to send it to an extra inlet and outlet pair
[send] and [receive] will still be slower than a direct connection for the same reason