On Wed, Oct 09, 2002 at 05:55:09PM -0400, Sam Tregar wrote: > On Wed, 9 Oct 2002, Tim Bunce wrote: > > > I'd guess it's related to the connect. > > Try it with DBI_PROFILE=6. > > Here's what I get: > > DBI::Profile: 0.001111 seconds 0.18% (10 method calls) prof_test.pl > '' => > 'FETCH' => > 0.000051s / 2 = 0.000026s avg (first 0.000010s, min 0.000010s, max >0.000041s) > 'STORE' => > 0.000047s / 2 = 0.000024s avg (first 0.000023s, min 0.000023s, max >0.000024s) > 'connect' => > 0.000238s > 'disconnect' => > 0.000037s > 'disconnect_all' => > 0.000009s > 'SELECT * FROM ?' => > 'execute' => > 0.000285s > 'finish' => > 0.000060s > 'prepare' => > 0.000384s > > So it looks like a bunch of automatic calls are ending up in the profile. > There are no finish(), disconnect() or disconnect_all() calls in the > script but they end up in the profile regardless.
(Actually there was a finish in the code you posted :) Perl called disconnect_all via an END block [*]. Not sure how disconnect got called - enabling a trace would show you. > Shouldn't they fall under this clause in the DBI::Profile docs: > > If the method call was invoked by the DBI or by a > driver then the call is currently ignored for > profiling because the time spent will be accounted for > by the original 'outermost' call. I probably need to find a better form of words. Something that talks about method calls on handles probably. > Also, where are those FETCH() and STORE() calls coming from? The two STOREs are probably DBI->connect code setting the default PrintError and AutoCommit. One FETCH is probably fetching the Profile attribute. A trace would show what the other one is. Tim. [*] I doubt any drivers implement disconnect_all so I might drop it one day.
