[CDBI] Make name_lc go fast
list at bereft.net
Tue Apr 10 02:29:37 BST 2007
Perrin Harkins wrote:
> On 4/3/07, Brad Bowman <list at bereft.net> wrote:
>> Rerunning with -r I get the opposite result, somehow not doing the lc
>> makes things slower.
> That's unexpected. Your first profile looks about how I'd expect --
> the I/O work done by the database takes the most time, followed by the
> accessor methods, but only because there's so many calls to them.
> Your second profile, I can't really explain. It might be disk
> caching, as Schwern pointed out. I'd try it again and see if the
> results are consistent.
I tried another input file and got a 5% (1:00 to 0:54) improvement,
2 runs in each configuration. As you would expect, the DBI::st::execute
dominated with 15-22%.
Repeating tests with the file from earlier in the thread, I get consistent
times and differences
Total time: 00:02:16 # name_lc
Total time: 00:01:49 # no name_lc
But occasionally I see execute further down the list, it has happened both
with and without name_lc:
dprofpp -r tmon.out
Total Elapsed Time = 54.04986 Seconds
Real Time = 54.04986 Seconds
%Time ExclSec CumulS #Calls sec/call Csec/c Name
10.5 5.674 5.674 146409 0.0000 0.0000 Class::Accessor::Fast::__ANON__
10.2 5.559 16.249 134667 0.0000 0.0000 Class::DBI::Column::__ANON__
10.1 5.487 10.696 134747 0.0000 0.0000 Class::DBI::Column::name_lc
9.50 5.135 5.135 16543 0.0003 0.0003 DBI::st::execute
5.49 2.970 2.980 752834 0.0000 0.0000 Class::Data::Inheritable::__ANON__
5.02 2.713 35.173 8270 0.0003 0.0043 Class::DBI::_insert
One in four profiles ends up like this, and execute is varying from 9.5% to
22% of the runtime. Since I'm using SQLite, I'd guess it's due to variations
in disk reading, writing and caching. See the benchmark output to follow
for a better measure.
It is bad taste to yawn in front of people. When one unexpectedly has to
yawn, if he rubs his forehead in an upward direction, the sensation will stop.
-- Hagakure http://bereft.net/hagakure/
More information about the ClassDBI