in reply to sprintf vs. substr (for zero-padded values)

If it's only slightly faster, I'd say stay the heck away from rewriting sprintf. You're just asking for trouble, anyway. In four lines of code you already have a nasty bug: 
sub one {
    my ($number) = @_;
    my $padded = sprintf("%09d",$number);
    $padded;
}

sub two {
    my ($number) = @_;
    my $padded = "000000000";
    my $length = length($number);
    substr($padded,(-$length),$length,$number);
    $padded;
}

print one(-6),"\n";     # -00000006
print two(-6),"\n";     # 0000000-6

print one(43/6),"\n";   # 000000007
print two(43/6),"\n";   # 7.16666666666667

[download]
It's just not worth the hassle to patch these bugs when sprintf is already sea-worthy.

Replies are listed 'Best First'.
Re: Re: sprintf vs. substr (for zero-padded values)
by Theseus (Pilgrim) on Jul 15, 2002 at 21:15 UTC
    Ahh... Admittedly, I didn't run that code through the mill looking for bugs, only drew it up quickly to benchmark it. Good catch, now I guess I know why people use sprintf for this even though it's a bit slower.
[reply]
      Here's the thing. It's not slower. It's actually faster, but your benchmark wasn't constructed properly. You used a constant, which I think Perl was optimizing away. Also, you were burying sprintf within a relatively expensive function call. Take a look at this: 
      use Benchmark qw[cmpthese];

sub one {
        sprintf("%09d",@_);
}

sub two {
        substr("000000000$_[0]",-9);
}

cmpthese(100, {
        one => sub { for(0..10000) { $_ = one($_) } },
        two => sub { for(0..10000) { $_ = two($_) } },
        tre => sub { for(0..10000) { $_ = sprintf("%09d", $_) } },
});

__DATA__
Benchmark: timing 100 iterations of one, tre, two...
       one: 12 wallclock secs (10.63 usr +  0.00 sys = 10.63 CPU) @  9
+.41/s (n=100)
       tre:  3 wallclock secs ( 3.38 usr +  0.00 sys =  3.38 CPU) @ 29
+.59/s (n=100)
       two: 12 wallclock secs (11.08 usr +  0.00 sys = 11.08 CPU) @  9
+.03/s (n=100)
      Rate  two  one  tre
two 9.03/s   --  -4% -69%
one 9.41/s   4%   -- -68%
tre 29.6/s 228% 214%   --

      [download]
      You're correct in your assumption that substr is faster, so long as the only number you need to process is "213" and you bury it in a subroutine call. You'll have to admit that in the real world users tend to ask for a little more functionality than that.

      It would seem that sprintf wins by a knockout.
[reply]
[d/l]
        Wow... ++tadman for discovering the flaw in my master plan, and for opening my eyes to how expensive calling a subroutine seems to be. Why is calling a sub so expensive?
[reply]

In Section Seekers of Perl Wisdom