On Thu, Oct 03, 2002 at 05:27:17PM -0400, Sam Tregar wrote: > On Tue, 1 Oct 2002, Tim Bunce wrote: > > > > - Build the sub-class in such a way that it does not accumulate > > > profiling data in-memory without limit. Devel::DProf and > > > Devel::Profiler accomplish this by doing buffered writes of raw deltas > > > into the data file and only assembling the full picture after the > > > fact. A quick think on the interface offered by DBI::Profile > > > suggests that this would be impossible without rewriting DBI::Profile. > > > > I don't see a problem. I think there's sufficient information stored > > in each node to allow nodes to be merged later. > > How would a sub-class of DBI::Profile get control at the appropriate point > to be able to implement this? I can see that I would need to implement > format(), but by the time format() is called the tree is already > completely built in-memory. To dump data before format() is called the > sub-class would need to get control after each node is created.
I think it would be enough to get control from time-to-time (which for mod_perl could be done as a cleanup handler). Then nstore() and clear out the profile data tree. At the END do one more nstore() and clear then trigger the code to read and merge the N files. > Here's my provisional naming scheme: Seems fine. > If this sounds acceptable, I'll take a first pass at POD docs for each and > send it to dbi-dev. Great. Thanks. Tim.
