Re: Perl commandments - index .vs. //
On Tue, Jan 09, 2001 at 12:50:08PM +, Piers Cawley wrote:
David Cantrell [EMAIL PROTECTED] writes:
Also index. These two snippets are equivalent:
if($foo=~/foo/) { ... }
if(index($foo, 'foo')!=-1) { ... }
I always want to do just plain if(index(...)) though.
ISTR that (for weird reasons), the regex version of that is faster.
If it is, it appears to be hidden by the other code ...
beta:~ $ perl match-cmp
Name "main::words" used only once: possible typo at match-cmp line 5.
Benchmark: running index, index_, regex, regex_, each for at least 10 CPU seconds...
index: 19 wallclock secs (18.71 usr + 0.00 sys = 18.71 CPU) @ 1.50/s (n=28)
index_: 19 wallclock secs (19.41 usr + 0.00 sys = 19.41 CPU) @ 1.49/s (n=29)
regex: 19 wallclock secs (19.11 usr + 0.01 sys = 19.12 CPU) @ 1.36/s (n=26)
regex_: 19 wallclock secs (18.62 usr + 0.00 sys = 18.62 CPU) @ 1.50/s (n=28)
beta:~ $ cat match-cmp
#!/usr/bin/perl -w
use Benchmark;
push @ARGV, '/usr/dict/words';
@words = ;
timethese( -10, {
regex = 'foreach $word (@words) { $word =~ /foo/ }',
regex_ = 'foreach (@words) { /foo/ }',
index = 'foreach $word (@words) { index $word, "foo" }',
index_ = 'foreach (@words) { index $_, "foo" }',
}
);
--
Chris Benson
Re: Perl commandments
Thou shalt optimise for programmer time unless absolutely necessary,
Thou shalt optimise for programmer time unless O(x(n)) O(y(n)) and n is
a suitably large value, where programmer time is both the time for the
current programming task and any future programming time that may be
expended maintaining this code.
Maybe that's not quite as snappy as the Brocard's. Hmm. It would be
easier if I could type omegas and stuff.
--
print "\n",map{my$a="\n"if(length$_6);' 'x(36-length($_)/2)."$_\n$a"} (
Name = 'Mark Fowler',Title = 'Technology Developer' ,
Firm = 'Profero Ltd',Web = 'http://www.profero.com/' ,
Email = '[EMAIL PROTECTED]', Phone = '+44 (0) 20 7700 9960' )
Re: Perl commandments
* Mark Fowler ([EMAIL PROTECTED]) wrote: Thou shalt optimise for programmer time unless absolutely necessary, Thou shalt optimise for programmer time unless O(x(n)) O(y(n)) and n is what are O(x(n)) and O(y(n)), i'm not familiar with the x and y notation -- Greg McCarroll http://www.mccarroll.uklinux.net
Re: Perl commandments
what are O(x(n)) and O(y(n)), i'm not familiar with the x and y notation
Okay, I was making it up on the fly; - They're meant to be the functions
you're implementing. Hence O(x(n)) is running time of x on the data n,
and the same for y.
I think the point I was trying to make about future programming time was
much more important.
Pah...I'm going to read some comics and install FreeBSD now...
Later.
Mark.
--
print "\n",map{my$a="\n"if(length$_6);' 'x(36-length($_)/2)."$_\n$a"} (
Name = 'Mark Fowler',Title = 'Technology Developer' ,
Firm = 'Profero Ltd',Web = 'http://www.profero.com/' ,
Email = '[EMAIL PROTECTED]', Phone = '+44 (0) 20 7700 9960' )
Re: Perl commandments
Greg McCarroll [EMAIL PROTECTED] writes: * Mark Fowler ([EMAIL PROTECTED]) wrote: what are O(x(n)) and O(y(n)), i'm not familiar with the x and y notation Okay, I was making it up on the fly; - They're meant to be the functions you're implementing. Hence O(x(n)) is running time of x on the data n, and the same for y. I think the point I was trying to make about future programming time was much more important. ok, but it gets more interesting as take into account moores law that reduces the effectiveness of optmisation by halving the improvement of the optimization every year, Err... Twice as fast is still twice as fast when it's running on a processor that's twice as fast as it would have been. I now can't remember where I read a fascinating piece on the value of more efficient algorithms as computers got faster. But it was worth reading. It was by that guy. Y'know, the guy who wrote that paper. -- Piers
Re: Perl commandments
* Mark Fowler ([EMAIL PROTECTED]) wrote: Err... Twice as fast is still twice as fast when it's running on a processor that's twice as fast as it would have been. I now can't remember where I read a fascinating piece on the value of more efficient algorithms as computers got faster. But it was worth reading. It was by that guy. Y'know, the guy who wrote that paper. ah, but its half the difference and thats whats important in this context, besides i think we'll all agree we are not talking about magnitudes of difference in this advice -- Greg McCarroll http://www.mccarroll.uklinux.net
Re: Perl commandments
In article [EMAIL PROTECTED] you write: ok, but it gets more interesting as take into account moores law that reduces the effectiveness of optmisation by halving the improvement of the optimization every year [...] This depends. If you're just doing an optimisation that changes one O(N) algorithm for another, then you're probably better off with the most clear version and wait for Moore's Law to help. Cycle-pinching optimisation doesn't really gain much anyway. [Mind you, I suspect that index and the equivalent regexen may have different O() scores. Discuss.] However, the problem is with programmers that don't really understand algorithms and implement something the "obvious" way, e.g. O(N^2) instead of O(NlogN) then this is not going to help when you attempt to scale your website or whatever to a million users instead of a test set of five. Of course, when the offending O(N^2) is found by the BPFH and the original coder LARTed, then the replacement O(NlogN) code should still indicate the API, be well commented and document where the algorithm came from (Mastering Algorithms with Perl / Knuth / wherever.) Of course, for small N, crude and simple O(N^2) algorithms can be faster than fancy ones, but for many cases, N is going to be directly proportional to your expected profit ;)
Re: Perl commandments
* Peter Corlett ([EMAIL PROTECTED]) wrote: In article [EMAIL PROTECTED] you write: ok, but it gets more interesting as take into account moores law that reduces the effectiveness of optmisation by halving the improvement of the optimization every year [...] This depends. If you're just doing an optimisation that changes one O(N) algorithm for another, then you're probably better off with the most clear version and wait for Moore's Law to help. Cycle-pinching optimisation doesn't really gain much anyway. [Mind you, I suspect that index and the equivalent regexen may have different O() scores. Discuss.] However, the problem is with programmers that don't really understand algorithms and implement something the "obvious" way, e.g. O(N^2) instead of O(NlogN) then this is not going to help when you attempt to scale your website or whatever to a million users instead of a test set of five. the best way to do this, if you see something is N^2 is to figure out how you could do it with a sort and hey presto it usually can be turned into NlogN+N .. NlogN -- Greg McCarroll http://www.mccarroll.uklinux.net
Re: Perl commandments
Greg McCarroll [EMAIL PROTECTED] writes: the best way to do this, if you see something is N^2 is to figure out how you could do it with a sort and hey presto it usually can be turned into NlogN+N .. NlogN This would involve beating aforementioned programmers round the head with Programming Pearls and if they _still_ don't get it, slamming their fingers under a full set of Knuth? -- Dave Hodgkinson, http://www.hodgkinson.org Editor-in-chief, The Highway Star http://www.deep-purple.com Apache, mod_perl, MySQL, Sybase hired gun for, well, hire -
Re: Perl commandments
David Hodgkinson [EMAIL PROTECTED] writes: Greg McCarroll [EMAIL PROTECTED] writes: the best way to do this, if you see something is N^2 is to figure out how you could do it with a sort and hey presto it usually can be turned into NlogN+N .. NlogN This would involve beating aforementioned programmers round the head with Programming Pearls and if they _still_ don't get it, slamming their fingers under a full set of Knuth? Programming Pearls! That's where the discussion of good algorithms used on accelerating hardware was. I think. -- Piers
Re: Perl commandments
Greg McCarroll [EMAIL PROTECTED] writes:
* Piers Cawley ([EMAIL PROTECTED]) wrote:
David Cantrell [EMAIL PROTECTED] writes:
On Tue, Jan 09, 2001 at 11:25:18AM +, Greg McCarroll wrote:
6.) regular expressions are not the only way to code, length and
substr are in the language for a reason
Also index. These two snippets are equivalent:
if($foo=~/foo/) { ... }
if(index($foo, 'foo')!=-1) { ... }
I always want to do just plain if(index(...)) though.
ISTR that (for weird reasons), the regex version of that is faster.
but of course we don't (shouldn't) program perl for program time
optimization but for programmer time optimization ;-)
So the regex wins on all counts then. Faster, clearer, shorter, easier
to maintain. The list goes on.
--
Piers
Re: Perl commandments
* Piers Cawley ([EMAIL PROTECTED]) wrote:
Greg McCarroll [EMAIL PROTECTED] writes:
* Piers Cawley ([EMAIL PROTECTED]) wrote:
David Cantrell [EMAIL PROTECTED] writes:
On Tue, Jan 09, 2001 at 11:25:18AM +, Greg McCarroll wrote:
6.) regular expressions are not the only way to code, length and
substr are in the language for a reason
Also index. These two snippets are equivalent:
if($foo=~/foo/) { ... }
if(index($foo, 'foo')!=-1) { ... }
I always want to do just plain if(index(...)) though.
ISTR that (for weird reasons), the regex version of that is faster.
but of course we don't (shouldn't) program perl for program time
optimization but for programmer time optimization ;-)
So the regex wins on all counts then. Faster, clearer, shorter, easier
to maintain. The list goes on.
nope daves was a bad example
--
Greg McCarroll http://www.mccarroll.uklinux.net
Re: Perl commandments
Greg McCarroll sent the following bits through the ether: in my original rule it was all to do with good programming style, not eeking out every bit of performance, my reply was actually that i thought dave choose a very grey area in terms of programming style Indeed. And someone mentioned another bit of code being faster, *without benchmarking it*. Leon -- Leon Brocard.http://www.astray.com/ yapc::Europehttp://yapc.org/Europe/ ... All new improved Brocard, now with Template Toolkit!
Re: Perl commandments
Leon Brocard [EMAIL PROTECTED] writes: Greg McCarroll sent the following bits through the ether: in my original rule it was all to do with good programming style, not eeking out every bit of performance, my reply was actually that i thought dave choose a very grey area in terms of programming style Indeed. And someone mentioned another bit of code being faster, *without benchmarking it*. This time. The discussion has been back and forth on various lists, usually with benchmarks. -- Piers
Re: Perl commandments
Piers Cawley sent the following bits through the ether: This time. The discussion has been back and forth on various lists, usually with benchmarks. Thou shalt optimise for programmer time unless absolutely necessary, when thou shalt Benchmark and quoth both the benchmark and the results. Leon -- Leon Brocard.http://www.astray.com/ yapc::Europehttp://yapc.org/Europe/ ... All new improved Brocard, now with Template Toolkit!
