Understood. The reason for my reluctance to do things one at a time is because I saw the effects of doing a C to perl callback for the comparator. Just calling the comparator (without actually using it's return value) drops my topN() routine from first, to second last place in the benchmark.

[ 1:01:43.25] P:\test>427029 -MAX=100 -N=10

10 from 100 (1 seconds)
100|99|98|97|96|95|94|93|92|91
         Rate    Ari    Buk     LR  BukLR   perl      C
Ari     464/s     --   -74%   -83%   -93%   -98%   -99%
Buk    1768/s   281%     --   -35%   -74%   -93%   -97%
LR     2731/s   488%    54%     --   -60%   -89%   -95%
BukLR  6876/s  1381%   289%   152%     --   -72%   -88%
perl  24678/s  5217%  1296%   804%   259%     --   -57%
C     57443/s 12276%  3149%  2004%   735%   133%     --

[ 1:02:07.47] P:\test>427029 -MAX=100 -N=10

10 from 100 (1 seconds)
100|99|98|97|96|95|94|93|92|91
         Rate   Ari     C   Buk    LR BukLR  perl
Ari     477/s    --  -32%  -72%  -79%  -92%  -98%
C       703/s   47%    --  -59%  -69%  -88%  -97%
Buk    1729/s  262%  146%    --  -24%  -71%  -93%
LR     2266/s  375%  222%   31%    --  -61%  -91%
BukLR  5881/s 1132%  737%  240%  159%    --  -77%
perl  25039/s 5146% 3463% 1348% 1005%  326%    --
[download]

There may be some fat that could be trimmed as I put the callback code in a separate C function (per the examples) in order to isolate all the stack manipulations.

That could probably be inlined with care, but I also tried calling a dummy C-function and it is very clear that it is the callback to perl, not the call to the C function that is chewing all the time. Once you get into the C code, it's better to stay and do as much work as possible in one go.

That said, I guess you could alway do the batching within the wrapping code also, which would make sense.