[26175] in Perl-Users-Digest
Perl-Users Digest, Issue: 8364 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sat Aug 27 18:05:32 2005
Date: Sat, 27 Aug 2005 15:05:08 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Sat, 27 Aug 2005 Volume: 10 Number: 8364
Today's topics:
Re: Is there any performance benefit to... <sdn.girths00869@zoemail.net>
Re: Making Datatypes Constant and Emulating Const Corre <sdn.girths00869@zoemail.net>
MJD HOP influence <perl@my-header.org>
Re: Using Crypt::DSA <sisyphus1@nomail.afraid.org>
Re: Using Crypt::DSA <mikef@ack.berkeley.edu>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sat, 27 Aug 2005 15:12:54 -0500
From: "Eric J. Roode" <sdn.girths00869@zoemail.net>
Subject: Re: Is there any performance benefit to...
Message-Id: <Xns96BFA5515AF8Fsdn.comcast@216.196.97.136>
-----BEGIN xxx SIGNED MESSAGE-----
Hash: SHA1
Derek Fountain <nomail@hursley.ibm.com> wrote in
news:430dc6bb$0$64033$892e7fe2@authen.white.readfreenews.net:
> I've inherited a piece of code that does something like this:
>
> sub func {
> my %hash = ();
>
> ...lots of code that populates and uses the hash
>
> %hash = ();
> }
>
> There are hundreds of these functions and they are called millions
of
> times in a procedure which takes hours, sometimes days, to
complete. The
> guy who wrote it was obviously concerned about performance.
>
> The question pertains to that resetting of the hash at the end of
> function. Does it do anything that exiting the function doesn't do?
In
> Java-land I've seen things like that to force the garbage collector
to
> jump in, but in Perl-land won't it just get optimised away? The
hash
> doesn't get that big, as far as I can see, and there's nothing
unusual
> in any of the hash processing code.
>
> Normally I'd just remove the line (or ignore it) but since it
appears in
> every one of these functions, and since removing a useful
optimisation
> might add an hour or two to my runtime, I thought I'd ask.
You are speculating, and asking others to speculate, about
performance
and optimization. This is almost always a Bad Idea.
Here's my answer, for what it's worth (not much): %hash = (), either
at the start (initialization) or end (cleanup) of a function, will
add no performance and subtract a tiny fraction of performance.
I'm a pretty smart guy, and I've been programming in Perl for ten
years, but that previous paragraph is almost certainly useless. Why?
Because it's a gut-feel answer, without knowledge of the rest of
your system, the rest of your code, and what interactions there may
be.
What you appear to be doing is making some educated guesses about
what is slow in your program, then changing them, then seeing if
things run faster. This is a very poor optimization technique. What
you must, MUST do is to *measure* the performance of your code. Then
see what parts of the code are taking up the lion's share of the
time, and work on optimizing THOSE parts. For all you or I know,
%hash = () might be very slow, but the portion of the program in
which it appears has far slower bits. So if you remove the %hash =
() lines, you'll have improved the speed, but not nearly as much as
if you had spent your time working on the real problems.
Profile your code. Do a production run with Devel::Prof or
Devel::SmallProf. Find out what portions of the code are taking up
all the time, and prioritize them. THEN come and ask us why this
function or that statement or whatever is taking so long.
Don't guess, and don't ask us to guess. Software engineering is not
about guesses.
- --
Eric
`$=`;$_=\%!;($_)=/(.)/;$==++$|;($.,$/,$,,$\,$",$;,$^,$#,$~,$*,$:,@%)=(
$!=~/(.)(.).(.)(.)(.)(.)..(.)(.)(.)..(.)......(.)/,$"),$=++;$.++;$.++;
$_++;$_++;($_,$\,$,)=($~.$"."$;$/$%[$?]$_$\$,$:$%[$?]",$"&$~,$#,);$,++
;$,++;$^|=$";`$_$\$,$/$:$;$~$*$%[$?]$.$~$*${#}$%[$?]$;$\$"$^$~$*.>&$=`
-----BEGIN xxx SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32) - WinPT 0.7.96rc1
iD8DBQFDEMm+Y96i4h5M0egRAsjBAKCA7zbQOYOR0ISYc5z3mT8QuNxOrgCgygXg
Q67VprcSY8cctzQVrzUcpLY=
=bs6r
-----END PGP SIGNATURE-----
------------------------------
Date: Sat, 27 Aug 2005 15:04:07 -0500
From: "Eric J. Roode" <sdn.girths00869@zoemail.net>
Subject: Re: Making Datatypes Constant and Emulating Const Correctness
Message-Id: <Xns96BFA3D1AFC42sdn.comcast@216.196.97.136>
-----BEGIN xxx SIGNED MESSAGE-----
Hash: SHA1
"Veli-Pekka Tätilä" <vtatila@mail.student.oulu.fi> wrote in
news:dekdub$lbc$1@news.oulu.fi:
[...]
> As to what kind of questions these const uses translate to in Perl the
> following come to mind.
> Is there a way of making:
> a. a scalar,
> b. an array
> c. a hash
> d. some reference (e,g. a blessed hash reference)
> e. A method
> constant inside a function or method?
use Readonly;
# a. Scalar:
Readonly $foo => 'Copyright 2005 by Sue D. Nymme';
# b. Array:
Readonly @bar => ('Harry', 'Hermione', 'Ronald');
# c. Hash:
Readonly %baz => {Bush => 'President', Cheney => 'Vice President'};
d. A reference is just a scalar. A referent is that to which the
reference points. A reference can be made Readonly, but that's not
usually very useful. If the referent is a scalar, array, or hash,
it can be made Readonly.
e. I'm not sure what you mean.
- --
Eric
`$=`;$_=\%!;($_)=/(.)/;$==++$|;($.,$/,$,,$\,$",$;,$^,$#,$~,$*,$:,@%)=(
$!=~/(.)(.).(.)(.)(.)(.)..(.)(.)(.)..(.)......(.)/,$"),$=++;$.++;$.++;
$_++;$_++;($_,$\,$,)=($~.$"."$;$/$%[$?]$_$\$,$:$%[$?]",$"&$~,$#,);$,++
;$,++;$^|=$";`$_$\$,$/$:$;$~$*$%[$?]$.$~$*${#}$%[$?]$;$\$"$^$~$*.>&$=`
-----BEGIN xxx SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32) - WinPT 0.7.96rc1
iD8DBQFDEMeaY96i4h5M0egRAswYAJ0TUrRxGrXotSIax+4AGbaRD5FkfgCgg7O9
olmMFTqPetRMX58r/VGh1Cw=
=ocR9
-----END PGP SIGNATURE-----
------------------------------
Date: Sat, 27 Aug 2005 19:15:46 +0200
From: Matija Papec <perl@my-header.org>
Subject: MJD HOP influence
Message-Id: <nm61h15skbonm6b05u67hjnmmprtvv3m9a@4ax.com>
It seems that functional approach is better suited for smaller "classes"
compared to classical OOP. Thinking in such way is challenging and pretty
new to me so I would be interested to hear suggestions; eg. is there some
flaw which can show in threading environment or how to optimize this very
basic OO example below.
===========================
use strict;
use warnings;
my $obj = Child(foo => 1, bar =>2);
$obj->(addcond => [id => 7]);
$obj->(addcond => [name => "lucas"]);
print $obj->(dumper => 1) if $obj->(can => "dumper");
sub Child {
#
# child class
#
our ($AUTOLOAD, $SUPER);
# child object data
my @foobar;
my $m = {
AUTOLOAD => sub {
my $self = shift;
print "There is no $AUTOLOAD!\n";
return;
},
dumper => sub {
my $self = shift;
$SUPER->(dumper => @_);
},
addcond => sub {
my $self = shift;
# get $SUPER via $self
# $AUTOLOAD contains current method name
$self->("SUPER")->($AUTOLOAD => @_);
},
};
return newclosure(usebase => \&Parent, $m, @_);
}
sub Parent {
#
# parent class
#
use Data::Dumper;
# object data
my %arg = @_;
my @cmdcond;
my $m = {
dumper => sub {
my $self = shift;
Dumper \@cmdcond, \%arg;
},
addcond => sub {
my $self = shift;
push @cmdcond, shift;
},
};
return newclosure($m, @_);
}
#########################################
sub newclosure {
#
our ($AUTOLOAD, $SUPER);
my $m = shift;
my $usebase;
my $super;
# inheritance?
if ($m eq "usebase") {
$usebase = shift;
$m = shift;
$super = &$usebase;
}
# core methods
$m->{SUPER} = sub { $super };
$m->{can} = sub {
my $self = shift;
my $sub = shift;
$m->{$sub} || $super->(can => $sub) || $m->{AUTOLOAD};
};
my $self;
return $self = sub {
my $sub = shift;
local $AUTOLOAD = $sub;
local $SUPER = $super;
# who you gonna call?
return
$m->{$sub} ? $m->{$sub}->($self, @_) :
$super->(can => $sub) ? $super->($sub, @_) :
$m->{AUTOLOAD}->($self, @_);
};
}
--
Matija
------------------------------
Date: Sun, 28 Aug 2005 05:20:18 +1000
From: "Sisyphus" <sisyphus1@nomail.afraid.org>
Subject: Re: Using Crypt::DSA
Message-Id: <4310bd20$0$28996$afc38c87@news.optusnet.com.au>
"Mike Friedman" <mikef@brillig.security.berkeley.edu> wrote in message
>
> Here's the entirety of my little test script:
>
> ------------------------------------------
> #!/usr/local/bin/perl
>
> use Crypt::DSA;
> use strict;
>
> my $dsa = new Crypt::DSA;
> my $key = Crypt::DSA::Key->new;
> my $filename;
>
> $filename = "./dsakey";
>
> $key = $dsa->keygen (
> Size => 1024,
> Verbosity => 1,
> ) or die $dsa->errstr();
>
> $key->write(
> Type => 'PEM',
> Filename => "$filename.priv",
> );
>
> $key->priv_key(undef);
>
> $key->write(
> Type => 'PEM',
> Filename => "$filename.pub",
> );
>
> exit;
> ------------------------------------------
>
> The result is that 'dsakey.priv' and 'dsakey.pub' have exactly
> the same contents, including the 'BEGIN DSA PRIVATE KEY',
> 'END DSA PRIVATE KEY' delimiters, even though I've undefined priv_key.
> What am I doing wrong?
>
Hmmm ... I run a copy'n'paste of that script and get 2 different files. The
'.priv' file has 'BEGIN DSA PRIVATE KEY', 'END DSA PRIVATE KEY' delimiters
and the '.pub' file has 'BEGIN PUBLIC KEY', 'END PUBLIC KEY' delimiters. The
base64 content is also different. Are we using the same version of
Crypt::DSA ? (I've got 0.13 which, I think, is the latest.)
I'm on Win32 - but I don't think that's going to account for the different
behaviour (in this instance :-)
Other than that, check 'perldoc Crypt::DSA::Key' for some possible clues.
Cheers,
Rob
------------------------------
Date: Sat, 27 Aug 2005 21:44:00 +0000 (UTC)
From: Mike Friedman <mikef@ack.berkeley.edu>
Subject: Re: Using Crypt::DSA
Message-Id: <deqmr0$1j2t$1@agate.berkeley.edu>
Sisyphus <sisyphus1@nomail.afraid.org> wrote:
>
> Hmmm ... I run a copy'n'paste of that script and get 2 different files. The
> '.priv' file has 'BEGIN DSA PRIVATE KEY', 'END DSA PRIVATE KEY' delimiters
> and the '.pub' file has 'BEGIN PUBLIC KEY', 'END PUBLIC KEY' delimiters. The
> base64 content is also different. Are we using the same version of
> Crypt::DSA ? (I've got 0.13 which, I think, is the latest.)
Rob,
I'm using version 0.12_1, which represents the latest FreeBSD port. I
prefer to install from ports because, especially in the case of software
that has lots of dependencies, installing manually becomes a real headache.
(A while back, when I had a Solaris box, I tried to install Crypt::RSA and
I could never, it seems, get to the end of installing all the dependencies!).
I see from CPAN that there have been some changes between 0.12 and 0.13, some
of which may affect what I've been doing (and asking about). For example,
I earlier inquired about the $sig->serialize method and it turns out that
was introduced in 0.13.
Anyway, there doesn't seem to be a port available yet for 0.13. Since I'm
just doing prototype testing, for an application that probably won't even be
running on FreeBSD, I don't want to get bogged down in version discrepancies.
I may just wait for a while to decide what to do.
Thanks.
Mike
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V10 Issue 8364
***************************************
