On Thu, Dec 17, 2009 at 09:27:58PM +0000, Nicholas Clark wrote:
> On Thu, Dec 17, 2009 at 09:13:44PM +0000, Tim Bunce wrote:
> > On Thu, Dec 17, 2009 at 05:08:11PM +0000, Nicholas Clark wrote:
>
> > > + NEW_FID => sub {
> > > + my (undef, $fid, $eval_fid, $eval_line, $flags, $size, $mtime, $name)
> > > = @_;
> > > + my ($new_fid, $new_eval_fid);
> > > + if($eval_fid) {
> > > + $new_eval_fid = $fids{$eval_fid};
> > > + confess("unknown eval_fid $eval_fid") unless defined $new_eval_fid;
> > > + $new_fid = $next_fid++;
> > > + $fids{$fid} = $new_fid;
> > > + } else {
> > > + $new_eval_fid = $eval_fid;
> > > + $new_fid = $file_to_fid{$name};
> >
> > I'd add $size and $mtime to the key (not used yet, but this'll make them
> > more important).
>
> I was thinking that if either differ, it should croak, as otherwise it's
> indicative of trying to merge profiles of different versions, which I
> assume would be incompatible.
A warning is certainly reasonable, a croak seems a bit extreme.
A typical use-case would be someone merging a bunch of profiles where a
minor change was made to a source file part-way through.
Adding $size and $mtime to the key will keep the line numbers distinct
between the old and new files[*] but the sub timings would still get
merged. That seems pretty useful.
[* so the same file should appear twice in the report (though probably
doesn't at the moment - bug), and, if the savesrc option is enabled,
each would show the right source code.]
> > NYTProf.xs is getting rather bloated. I'd love to get the NYTP_* i/o
> > functions moved out. (I'd even wondered about an libnytpio.so that other
> > tools could link to.)
> >
> > Any chance you could add a FileHandle.xs containing the NYTP_* i/o
> > functions and the XS interface code for them?
>
> Yes, but, the XS code *also* interfaces output_int(), output_nv() and
> output_str(), none of which are (currently) "NYTP_*" i/o functions.
Does that matter if they're made non-static and FileHandle.o is
added to ld command that makes NYTProf.so?
> Should they be renamed to NYTP_* and moved there?
I was thinking along vagely similar lines last night.
Currently the "NYTP_*" i/o functions are currently all very low-level:
NYTP_tell(NYTP_file file) {
NYTP_type_of_offset(NYTP_file file) {
NYTP_start_deflate(NYTP_file file) {
NYTP_start_inflate(NYTP_file file) {
NYTP_open(const char *name, const char *mode) {
NYTP_gets(NYTP_file ifile, char *buffer, unsigned int len) {
NYTP_read_unchecked(NYTP_file ifile, void *buffer, size_t len) {
NYTP_read(NYTP_file ifile, void *buffer, size_t len, const char *what) {
NYTP_write(NYTP_file ofile, const void *buffer, size_t len) {
NYTP_printf(NYTP_file ofile, const char *format, ...) {
NYTP_flush(NYTP_file file) {
NYTP_eof(NYTP_file ifile) {
NYTP_fstrerror(NYTP_file file) {
NYTP_close(NYTP_file file, int discard) {
we could add output_int(), output_nv() etc. 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, ...)
...
(output_int(), output_nv() etc. could be made private to that 'library'.)
That would give us encapsulation of the file format. nytprofmerge could
be significantly faster with an XS interface to those functions.
Tim.
--
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]
