On Tue, Feb 09, 2010 at 05:46:23PM +0000, Tim Bunce wrote:
> On Tue, Feb 09, 2010 at 03:33:53PM +0000, Nicholas Clark wrote:
> > On Tue, Feb 09, 2010 at 03:04:23PM +0000, Tim Bunce wrote:
> >
> > > I'd guess you'd see a significant gain in performance by changing
> > > TIME_BLOCK & TIME_LINE handling along these lines...
> > >
> > > - Move the output_tag_int(out, NYTP_TAG_TIME_BLOCK... code
> > > out of DB_stmt into a new function.
> > > - Check the return value of the TIME_BLOCK & TIME_LINE handlers.
> > > - If false then call the new function using the (possibly now
> > > modified)
> > > cb_args[i] values.
> > >
> > > That'll save you half a bazillion $out->write & $out->output_int method
> > > calls. The code would just edit $_[4] and return;
> >
> > I had assumed that I was going to implement your earlier plan (first):
> >
> > > [...] but I think a better
> > > approach would be to create a new layer of higher-level functions:
> > >
> > > nytp_write_stmt_time(NYTP_file ofile, elapsed, fid, line, block_line,
> > > sub_line);
> > > nytp_write_new_fid(NYTP_file ofile, id, eval_fid, eval_line_num, ...)
> > >
> > > That would give us encapsulation of the file format. nytprofmerge could
> > > be significantly faster with an XS interface to those functions.
>
> That would be cool.
>
> I was just thinking of the above as a quick hack for a useful gain.
>
> > I'm just not yet sure about the C source file names. I assume that the file
> > handle XS stays in Devel::NYTProf::FileHandle, so it's a name for the
> > low(er)
> > level IO code, such as output_int() and friends.
>
> Seems reasonable. Though perhaps FileHandle should disappear and the
> guts of it become private to the new higher-level interface.
> Trying to keep FileHandle around may give more pain for little gain.
There seem to be several parts. And I'm not sure how to name them
1: The C functions in FileHandle.xs, prefixed NYTP_, which deal with the low
level operations of moving data in and out of files
2: The building blocks immediately on top of them (output_{int,nv,str})
currently in NYTProf.xs
3: The higher level abstractions (that don't yet exist) - a subroutine per
tag type that we need to output
4: Potentially a C callback based input parser
(With NYTProf.xs refactored to supply callbacks to read the data)
There would need to be XS wrappers to (at least) the open and close functions
in (1), and everything in (3). (2) is what nytprofmerge currently uses. In
theory we could abolish wrappers of (2), *but* it would be useful to keep them
to facilitate prototyping and doing things outside the current applications.
So in theory all of the above C functions could be in one file.
Or in two. (1) vs (2,3,4)
Or in two. (1,2) vs (3,4)
I'm not sure which.
And I'm not sure whether the XS wrappers go in the same file, or a different
file. And 1 namespace or several.
Or what names anything has. Particularly as "profile" could mean the abstract
concept of a profile, or routines to manipulate a file on disk in our format.
[ie (2,3,4) above]
Nicholas Clark
--
You've received this message because you are subscribed to
the Devel::NYTProf Development User group.
Group hosted at: http://groups.google.com/group/develnytprof-dev
Project hosted at: http://perl-devel-nytprof.googlecode.com
CPAN distribution: http://search.cpan.org/dist/Devel-NYTProf
To post, email: [email protected]
To unsubscribe, email: [email protected]
