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.
> > - What should I name it? Ideas: DBIx::DProf, DBIx::Profiler...
>
> If we can agree on the design (set of modules and interfaces) I'd
> happily include it in the DBI distribution - if that's okay with you.
Sounds good. Here's my provisional naming scheme:
DBI::ProfileDumper - sub-class of DBI::Profile, outputs profile data in
a machine-readable format at process termination
DBI::ProfileData - loads data dumped by DBI::ProfileData and offers
slicing, dicing and formatted reporting
dbi_prof - command-line tool that uses DBI::ProfileData to
provide a similar interface to dprofpp
If this sounds acceptable, I'll take a first pass at POD docs for each and
send it to dbi-dev.
-sam
