|
This block is optimized for laziness and not performance since it
returns before finishing its input based on whatever M is.
This means that m=1, n=1, this block produces 1000's of outputs per input buffer,
and its not really what I am looking to benchmark...
ironically, keep_m_in_n crappy implementation makes for big wins on GRAS
either due to lower scheduler overhead or locking contentions easier.
However, its crazy number of tiny outputs really rails on the
mailbox queue of the next block in the chain and causes
the caching allocators to get very exited.
I guess thats all fine since the block is meant to be lazy...
But I cant measure the effectiveness of a typical allocator situation.
Signing off...
|
