Re: Microptomisation games
On Fri, 28 Feb 2003, darren chamberlain wrote: my $left = shift; # this/self my $right = shift; # the other obeject my $rev = shift; # have the args been reversed by perl? But you can do that anyway: my ($left # this/self $right # the other obeject $rev) = @_; # have the args been reversed by perl? But the latter method is more susceptible to maintainance errors in my view. Jason Clifford -- UKFSN.ORG Finance Free Software while you surf the 'net http://www.ukfsn.org/ Get the T-Shirt Now
Re: Microptomisation games
Adman Kennedy wrote:
sub foo {
my $this = shift;
my $that = shift;
my $theother = shift;
print $this, $that, $theother;
}
I tend to use this style, maily because it allows me to write comments
next to each of the things I'm shifting off:
sub add
{
my $left = shift; # this/self
my $right = shift; # the other obeject
my $rev = shift; # have the args been reversed by perl?
...
}
Mostly I just do
sub foo
{
my $this = shift
my %args = @_;
...
}
or even (using params validate)
sub foo
{
my $this = shift;
my %args = validate(@_, { ... });
..
}
Of course that's terribly slow in comparison. On the other hand, it makes
the code easier to extend. As always, it's a trade off.
Let's have a look at the comparative speeds:
[host26:~] mark% perl function_call.pl
Benchmark: timing 1000 iterations of array, bare, hash, shif...
array: 59 wallclock secs (55.65 usr + 0.00 sys = 55.65 CPU) @
179694.52/s (n=1000)
bare: 43 wallclock secs (39.45 usr + 0.00 sys = 39.45 CPU) @
253485.42/s (n=1000)
hash: 154 wallclock secs (141.49 usr + 0.00 sys = 141.49 CPU) @
70676.37/s (n=1000)
shif: 68 wallclock secs (63.60 usr + 0.00 sys = 63.60 CPU) @
157232.70/s (n=1000)
Rate hash shif array bare
hash 70676/s-- -55% -61% -72%
shif 157233/s 122%-- -13% -38%
array 179695/s 154% 14%-- -29%
bare 253485/s 259% 61% 41%--
(the script is at the end of this email)
So, in this particular example, shift ran 14% faster than using an array,
but ran a whopping 122% faster than using the named parameter calling.
Obviously, this is going to be effected by many things (number of
parameters, element names, hashing algo used.)
(For the record this is perl, v5.6.0 built for darwin)
Mark.
script
#!/usr/bin/perl
use strict;
use warnings;
use Benchmark qw(cmpthese);
cmpthese( 10_000_000,
{
bare = 'bare(foo,bar,bob)',
array = 'array(foo,bar,bob)',
shif = 'shif(foo,bar,bob)',
hash = 'hash(foo = foo, bar = bar, bob = bob)'
});
sub bare { $_[0], $_[1], $[2] }
sub array
{
my ($foo, $bar, $bob) = @_;
$foo, $bar, $bob
}
sub shif
{
my $foo = shift;
my $bar = shift;
my $bob = shift;
$foo, $bar, $bob
}
sub hash
{
my %arg = @_;
$arg{foo}, $arg{bar}, $arg{bob}
}
end of script
--
#!/usr/bin/perl -T
use strict;
use warnings;
print q{Mark Fowler, [EMAIL PROTECTED], http://twoshortplanks.com/};
Re: Microptomisation games
- Original Message -
From: Adam Kennedy [EMAIL PROTECTED]
Sent: Thursday, February 27, 2003 1:18 PM
Any function that get's called a million times deserves to be either
micro-optomised, or even better inlined. ( inlining saves more than any
of the above steps ).
This is kind of a newbie question, but I never had read anything about
this: what is an inlined perl function? Can somebody point me some
resources about this technique?
Thank you very much, use Perl;eval { join ', ', 'Mr. Kennedy',
$list-subscribers(); }no Perl;.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Luis Campos de Carvalho
Computer Science Student
OCP DBA Oracle Unix Sys Admin
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Re: Microptomisation games
On Fri, 28 Feb 2003, Luis Campos de Carvalho wrote: Any function that get's called a million times deserves to be either micro-optomised, or even better inlined. ( inlining saves more than any of the above steps ). This is kind of a newbie question, but I never had read anything about this: what is an inlined perl function? Can somebody point me some resources about this technique? It's the opposite of putting things neatly in subroutines - rather than calling, pass parameters, and all the processing junk that goes with it, you just stick the code right in the main routine. I stumbled into a good example of that, which didn't intend to be, in URI::Escape (http://search.cpan.org/author/GAAS/URI-1.23/URI/Escape.pm). As it advises, and the benchmarks quoted backs up, don't use the unescape routine for speed, it's better just to put the regexp into your main code. the hatter
Re: Microptomisation games
At 12:27 GMT 28.02.03, [EMAIL PROTECTED] wrote: : : This is kind of a newbie question, but I never had read anything about : this: what is an inlined perl function? Can somebody point me some : resources about this technique? Inline: Write Perl subroutines in other programming languages. http://search.cpan.org/author/INGY/Inline-0.44/Inline.pod --cal for it's such a lovely day, to have to always feel this way
Re: Microptomisation games
* Mark Fowler mark at twoshortplanks.com [2003-02-28 06:49]:
I tend to use this style, maily because it allows me to write comments
next to each of the things I'm shifting off:
sub add
{
my $left = shift; # this/self
my $right = shift; # the other obeject
my $rev = shift; # have the args been reversed by perl?
But you can do that anyway:
sub add
{
my ($left # this/self
$right # the other obeject
$rev) = @_; # have the args been reversed by perl?
...
(darren)
--
The best book on programming for the layman is Alice in Wonderland;
but that's because it's the best book on anything for the layman.
-- Alan Perlis
Re: Microptomisation games
On Fri, Feb 28, 2003 at 03:18:34AM +1100, Adam Kennedy wrote: I did quite a bit of microopomisation during early work on the PPI module. snip The real question is when does it become significant. In my experience the sort of optomisation you see above become valuable at about 100,000 - 1,000,000 function invocations. Any function that get's called a million times deserves to be either micro-optomised, or even better inlined. ( inlining saves more than any of the above steps ). Is it time to consider re-writing in a compiled language at this point? You can optimise a nice Perl daemon until its very fast.. but then I can come along and write a fully-optimised C version, and probably reach another order of magnitude in speed. Horses for courses though. tjc -- Turning and turning in the widening gyre The falcon cannot hear the falconer; Things fall apart, the centre cannot hold; Mere anarchy is loosed upon the world.
Re: Microptomisation games
On Fri, Feb 28, 2003 at 05:39:23AM -0800, Toby|Wintrmute wrote: On Fri, Feb 28, 2003 at 03:18:34AM +1100, Adam Kennedy wrote: I did quite a bit of microopomisation during early work on the PPI module. snip The real question is when does it become significant. In my experience the sort of optomisation you see above become valuable at about 100,000 - 1,000,000 function invocations. Any function that get's called a million times deserves to be either micro-optomised, or even better inlined. ( inlining saves more than any of the above steps ). Is it time to consider re-writing in a compiled language at this point? You can optimise a nice Perl daemon until its very fast.. but then I can come along and write a fully-optimised C version, and probably reach another order of magnitude in speed. Or I can profile the original Perl daemon, find that 10% of the code that takes 90% of the time, re-write just that bit in C using Inline::C, and be down the pub before you. Hopefully. Although for the general case I believe it will hold true. Nicholas Clark
Re: Microptomisation games
On Friday 28 February 2003 13:39, Toby|Wintrmute wrote: Is it time to consider re-writing in a compiled language at this point? You can optimise a nice Perl daemon until its very fast.. but then I can come along and write a fully-optimised C version, and probably reach another order of magnitude in speed. maybe ... but not certainly .. it depends. much of perls internals is written in very tightly coded, highly efficient C that will most likely beat your 'fully optimised' C because Larry Walls brain is bigger than yours :) ... it depends on where the load is really, if its already spending most of its time in a higly tuned bit of the perl core, porting to C or C++ might not be such a gain after all -- Robin Szemeti
Microptomisation games
I did quite a bit of microopomisation during early work on the PPI module.
sub foo {
my ($this, $that, $theother) = @_;
print $this, $that, $theother;
}
is slower than
sub foo {
my $this = shift;
my $that = shift;
my $theother = shift;
print $this, $that, $theother;
}
is slower than
sub foo {
print $_[0], $_[1], $_[2];
}
I use the second form these days in most of my coding.
The real question is when does it become significant.
In my experience the sort of optomisation you see above become valuable
at about 100,000 - 1,000,000 function invocations.
Any function that get's called a million times deserves to be either
micro-optomised, or even better inlined. ( inlining saves more than any
of the above steps ).
I managed to double the speed of PPI by doing that sort of
micro-optimisation.
If a function is getting executed less than 100,000 times, the point
becomes largely moot and becomes a style choice.
Adam
