Ovid has asked for the wisdom of the Perl Monks concerning the following question:

I need to profile some code, but I've discovered that the program behaves differently when using Devel::DProf. Below is my test case and the ouput. I've duplicated this bug with Perl 5.8.0 on two computers, both running RH Linux. I'll send this off to P5P if it's not a known issue, but in the meantime, have I missed something?

  #!/usr/bin/perl
  use strict;

  parse(1,0);

  sub parse {
    while (defined(my $number = shift)) {
      print "Number: $number\n";
      &parse if $number;
    }
  }

[download]

And the results:

  $ perl test.pl
  Number: 1
  Number: 0

  $ perl -d:DProf test.pl
  Number: 1
  Number: 0
  Number: 0

[download]

By changing the recursive call to parse() to the following:

  parse(@_) if $number;

I get the following results:

  $ perl test.pl
  Number: 1
  Number: 0
  Number: 0

  $ perl -d:DProf test.pl
  Number: 1
  Number: 0
  Number: 0

[download]

However, that looks like both versions are wrong because somehow the final zero is getting read twice by shift. What am I missing?

Cheers,
Ovid

New address of my CGI Course.

Replies are listed 'Best First'.
Re: Bug in Devel::DProf?
by Abigail-II (Bishop) on Aug 15, 2003 at 22:22 UTC
    Well, as pointed out, if you use parse (@_), you should see three lines, 2 from the initial call to parse, and one from the recursive call. If you examine carefully, you'll notice that the first Number: 0 comes from the recursive call, and the last Number: 0 is from the initial call, in the second iteration of the while.

    So, what about doing this with &parse you may ask. Well, if you call from sub1, &sub2, then sub1 and sub2 will actually share @_! Look for instance at: 

    #!/usr/bin/perl

use strict;
use warnings;

sub foo {
    print "Foo: [@_]\n";
    shift;
}

sub bar {
    print "Bar: [@_]\n";
    &foo;
    print "Bar: [@_]\n";
}

bar 1, 2
 
__END__
Bar: [1 2]
Foo: [1 2]
Bar: [2]

    [download]

    Shifting off an element of @_ in foo() is noticeable in bar().

    Leaves us the question, why three lines in perl -d:DProf test.pl when the function is called as &parse? For that, I do not know the answer. I can just guess that DProf puts each function in some kind of wrapper, causing the arguments to get duplicated.

    Abigail

[reply]
[d/l]
Re: Bug in Devel::DProf?
by fletcher_the_dog (Friar) on Aug 15, 2003 at 21:07 UTC
    In your second example they both are RIGHT. When calling parse(@_) recursively the new instance of parse creates its own @_. When you shift @_ in the recursive call you are NOT shifting the @_ of the parent caller. Try this: 
    #!/usr/bin/perl
  use strict;
  my $call = 0;
  parse(1,0);
  
  sub parse {
    my $curcall=++$call;
    print "My parameters: @_\n";
    while (defined(my $number = shift)) {
      print "Number: $number from call $curcall\n";
      parse(@_) if $number;
    }
  }

OUTPUT:

My parameters: 1 0
Number: 1 from call 1
My parameters: 0
Number: 0 from call 2
Number: 0 from call 1

    [download]
    Notice how the second printing of '0' is from call 1 and not call 2?
[reply]
[d/l]
Re: Bug in Devel::DProf?
by antirice (Priest) on Aug 15, 2003 at 21:05 UTC

    The first case definitely seems to be a bug with DProf. However, the second case does not seem to be a bug with perl since you are passing by value and the original @_ still contains 0 after the recursive call to parse has finished.

    Hope this helps.

    antirice    
    The first rule of Perl club is - use Perl
    The     ith rule of Perl club is - follow rule i - 1 for i > 1

[reply]

Back to Seekers of Perl Wisdom