Skip Menu |

This queue is for tickets about the Apache-Filter CPAN distribution.

Report information
The Basics
Id: 263
Status: resolved
Worked: 10 min
Priority: 0/
Queue: Apache-Filter

People
Owner: Nobody in particular
Requestors: greg [...] webzavod.ru
Cc:
AdminCc:

Bug Information
Severity: Normal
Broken in: 1.019
Fixed in: (no value)



Subject: reference parameters in print()
Apache::Filter::print overrides Apache::Request::print that have ability to accept scalar references instead of values as parameters. That minimize unneeded data copying. But Apache::Filter::print do it's job like print STDOUT @_; so references are not derefered and functionality is broken.
Yeah, I suppose I should fix this. I've been resisting it, because I've never liked this peculiarity of Apache::print, and emulating it would mean a small across-the-board performance hit. Also, the entries in @_ are aliases to the original variables, *not* copies, so I'm still not convinced that the auto-dereferencing behavior actually has any benefit. But to be consistent with Apache::print, I should fix it. -Ken
From: "Gregory Belenky" <greg [...] webzavod.ru>
To: <bug-Apache-Filter [...] rt.cpan.org>
Subject: Re: [cpan #263] reference parameters in print()
Date: Fri, 8 Feb 2002 11:22:52 +0400
| Also, the entries in @_ are aliases to the original variables, *not* copies, so I'm still not convinced that the auto-dereferencing behavior actually has any benefit. There may be a benefit when you pass _reference_ to large chunk of data from one sub of your application to another and finally print it instead of passing data value. Gregory Belenky WebZavod (http://www.webzavod.ru) programmer
[greg@webzavod.ru - Fri Feb 8 02:22:13 2002]: Show quoted text
> There may be a benefit when you pass _reference_ to large chunk of data from > one sub of your application to another and finally print it instead of > passing data value.
Well, the way you pass data around in your application doesn't really have anything to do with how you pass it to print() at the end. Also, I've run a benchmark, and it indicates that using references just for their own sake actually slows things down: -------------------------------------------------------------------- [junior:~/bin/test] ken% cat bench.pl #!/usr/bin/perl use Benchmark; open my($fh), "> /dev/null" or die $!; sub print_regular { print $fh @_ } sub print_deref { print $fh map {ref() ? $$_ : $_} @_ } $long_string = "x" x 100_000; $long_string2 = "y" x 100_000; timethese(500_000, { 'print_regular' => 'print_regular($x, $y)', 'print_deref' => 'print_deref(\$x, \$y)', }); [junior:~/bin/test] ken% perl bench.pl Benchmark: timing 500000 iterations of print_deref, print_regular... print_deref: 6 wallclock secs ( 5.34 usr + 0.00 sys = 5.34 CPU) @ 93632.96/s (n=500000) print_regular: 1 wallclock secs ( 1.73 usr + 0.00 sys = 1.73 CPU) @ 289017.34/s (n=500000)
D'oh - there were typos in the benchmark that made it a bogus test. Here's a better one, with similar comparative results: ----------------------------------------------------------------- [junior:~/bin/test] ken% cat ref.pl #!/usr/bin/perl use Benchmark; open my($fh), "> /dev/null" or die $!; sub print_regular { print $fh @_ } sub print_deref { print $fh map {ref() ? $$_ : $_} @_ } $x = "x" x 100_000; $y = "y" x 100_000; timethese(5_000, { 'print_regular' => 'print_regular($x, $y)', 'print_deref' => 'print_deref(\$x, \$y)', }); __END__ [junior:~/bin/test] ken% perl ref.pl Benchmark: timing 5000 iterations of print_deref, print_regular... print_deref: 72 wallclock secs (41.73 usr + 0.00 sys = 41.73 CPU) @ 119.82/s (n=5000) print_regular: 22 wallclock secs (15.55 usr + 0.00 sys = 15.55 CPU) @ 321.54/s (n=5000) ----------------------------------------------------------------- I think I'm going to leave it as-is. If someone wants to give me a patch that switches between the two behaviors at compile time though, I'll probably apply it.