Thanks for suggestions. My benchmarks shown here were rather synthetic; they were for illustrative purposes mostly. I don't usually try to optimize my scripts to the ground, but this case is very special for me. I won't go into detail but I really need to shave off all unnecessary code to save CPU cycles. For me, CPU utilization has always meant code speed and so I was trying to make my code faster so it could run cleaner with regards to CPU. I'm not fanatic about it and I won't rewrite it in C, that would give marginal results vs huge overhead; I consider it an exercise I can afford spending my time at while I'm waiting for the next project phase to begin. Besides, it looked like a perfect opportunity to acquaint myself with Devel::NYTProf, finally. :)

I must tell that it was very educational for me this way; not only I learnt that newer Perl doesn't mean faster Perl - as your table would suggest, it's actually vice versa - but also I was never aware that speed and CPU utilization are not directly related. In fact, I have discovered it just now and I'm still trying to find an explanation to the fact that the same script ran with Perl 5.6.1 consumes ~4% CPU, but it goes up to ~6% with Perl 5.8.9 and even higher to ~8% with 5.14.1, as reported by prstat. But the test results suggest that it's faster with 8.9! Frankly, I'm at loss - the only explanation I can think up is that Perl 5.6.1 shipped with Solaris has some magic optimizations built in vs vanilla Perl. perl -V does state that it has 48 patches applied, but that doesn't explain the same 2% 5.14 adds over to 5.8. I need to dig up Solaris 10 DVD, set up another virtual machine and try it there - Sol10 ships with Perl 5.8 as standard. But it's black magic anyway.

Regarding the database optimization, I fully agree with you. If it was any other database engine I would spend my time juggling SQL statements; in case of SQLite it's not so advanced and doesn't have a lot of options to play with. But it's not the case either because the problem was not in SQLite code itself which is highly optimized and blazingly fast, the problem was (and is) in DBD::SQLite that somehow runs twice slower when you use execute_array instead of execute. I tried to check if it was Perl issue instead, and discovered that not all Camels are created equal... It led me to this meditation.

Regards,
Alex.