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.

In reply to Re^2: Why "Modern Perl" is slower than "Legacy Perl"? by dwalin
in thread Why "Modern Perl" is slower than "Legacy Perl"? by dwalin

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.