Re: When perl is not quite fast enough
[apache.org keeps on timing out :( reposting 3rd time :(] Jeff AA wrote: >>-Original Message- >>From: Stas Bekman [mailto:[EMAIL PROTECTED]] >>Sent: 16 December 2002 13:22 >>To: [EMAIL PROTECTED] >>Subject: When perl is not quite fast enough >> >> >>While reading Mark Fowler excelent Perl Advent Calendar >>(http://www.perladvent.org/2002/) 6th entry: >>http://www.perladvent.org/2002/6th/, in the references >>section I've noticed a >>link to Nicolas Clark's notes from his YAPC::EU::2002 >>presentation, on how to >>make your perl code faster: http://www.ccl4.org/~nick/P/Fast_Enough/ > > > Dear ModPerl Lister, > > I have two questions: > > 1) In this list, I have seen folks asking general Perlish questions >told to take their discussions elsewhere, along with the useless >recommendation that they browse lists.perl.org - I have done this >several times and joined a few of the lists, but only ever found >lists that were rather beginner. I have also lurked in some of the >groups.yahoo.com pearly lists without finding the right level. > >- can folks name any specific useful intermediate/advanced > Perl lists? i.e. Perl 4+ years in a commercial env I think the comp.lang.perl.moderated newsgroup (and if not accepted by the first, comp.lang.perl.misc) used to be the best resource to discuss general perl things. It's been a while since I've last used it, so I'm not sure if it's still a good resource. If others can confirm that it's still useful, I'll add that resource to: http://perl.apache.org/docs/offsite/other.html#Perl If you know of other good resources for general perl discussions which aren't already listed at lists.perl.org please let us know and we will update that section. It's probably a good idea to link from http://perl.apache.org/help/index.html to http://perl.apache.org/docs/offsite/other.html to help direct those seeking help on other topics in the vicinity of mod_perl. > 2) I have one common approach to speed improvement that is not >mentioned at all, to do with symbol table manipulation for >functions, that I would like to polish via a list discussion > >- is this list appropriate for a thread discussing Perlish >performance in general? I would guess that symbol table fiddles >might be risky in a mod_perlish env. It sounds good to me if it helps other mod_perl users to improve their code's performance. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: AUTOLOAD in mod_perl (was Re: When perl is not quite fast enough)
Christopher Grau wrote:
I may be veering off-topic, but I've started doing similar things in my
own code (generating accessor methods via AUTOLOAD). I ended up writing
`Class::Autoload,' which I intend to upload to CPAN when I'm done with
documentation and testing.
Mine was very simple and didn't need to handle any odd cases, which was
why I didn't bother using a CPAN module. I would probably check
Class::MethodMaker before doing it this way again.
I had this in a shared class:
Package Util;
sub build_accessors {
my ($class, $pkg, $attr_names) = @_;
no strict 'refs';
foreach my $attr_name (@{$attr_names}) {
*{$pkg . "::$attr_name"} = sub { return $_[0]->{$attr_name}; };
}
}
And then I would put something like this in the classes that needed it:
BEGIN {
my @attr_names;
@attr_names = qw(
foo
bar
baz
);
Util->build_accessors(__PACKAGE__, \@attr_names);
}
- Perrin
AUTOLOAD in mod_perl (was Re: When perl is not quite fast enough)
Perrin (et al... cc'ing this back to the list) Thanks for this information... it is confirming what I originally thought, so I don't need to change my code (yet). But I wanted to post it back to the list to everyone else can benefit from it. I personally tend to avoid AUTOLOAD, only because it is a piece of perl "magic" that can be super-confusing to developers coming to perl (and mod_perl) from other languages (um, Java) and I think there's a voodoo-level involved that's a bit high for my tastes. In the one place I use it, I don't generate anything, just trap calls to methods with AUTOLOAD and perform a lookup based on the arguments. If it really is that slow, maybe I'll even rewrite that to use something other than AUTOLOAD. Cheers! Kyle Dawkins Central Park Software On Tuesday, Dec 17, 2002, at 13:13 US/Eastern, Perrin Harkins wrote: kyle dawkins wrote: Sorry to mail you directly... can you just give me two cents on your comment below about AUTOLOAD, mod_perl and memory sharing? I use AUTOLOAD in one module to perform accessors and I wonder if there's a better way to save memory. AUTOLOAD is kind of slow, so most people put something in there to define their accessors as subs by manipulating the symbol table. It's easy, and Damian's book has an example. In mod_perl, you want any methods that you expect to be called to be defined in the parent process so they will be shared. I do this by building all of the accessors in a BEGIN block in my module which is called when I use it in startup.pl. - Perrin
Re: When perl is not quite fast enough
Jeff AA wrote: I have two questions: 1) In this list, I have seen folks asking general Perlish questions told to take their discussions elsewhere, along with the useless recommendation that they browse lists.perl.org - I have done this several times and joined a few of the lists, but only ever found lists that were rather beginner. I have also lurked in some of the groups.yahoo.com pearly lists without finding the right level. - can folks name any specific useful intermediate/advanced Perl lists? i.e. Perl 4+ years in a commercial env In addition to perlmonks.org, the usenet groups and IRC have the highest concentration of experienced Perl coders. I would guess that symbol table fiddles might be risky in a mod_perlish env. No more so than any other place. The biggest risk is that symbol table hacks are usually bizarre and hard to read. The Apache::PerlRun module modifies the symbol table in order to reset globals, and I've done really simple things with it to automatically build accessor methods (which can be better than AUTOLOAD with mod_perl because of memory sharing). - Perrin
Re: When perl is not quite fast enough
Hi!
On Tue, Dec 17, 2002 at 08:32:01AM -, Jeff AA wrote:
>- can folks name any specific useful intermediate/advanced
> Perl lists? i.e. Perl 4+ years in a commercial env
What about perlmonks?
http://www.perlmonks.org
--
#!/usr/bin/perl http://domm.zsi.at
for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/}
RE: When perl is not quite fast enough
> -Original Message- > From: Stas Bekman [mailto:[EMAIL PROTECTED]] > Sent: 16 December 2002 13:22 > To: [EMAIL PROTECTED] > Subject: When perl is not quite fast enough > > > While reading Mark Fowler excelent Perl Advent Calendar > (http://www.perladvent.org/2002/) 6th entry: > http://www.perladvent.org/2002/6th/, in the references > section I've noticed a > link to Nicolas Clark's notes from his YAPC::EU::2002 > presentation, on how to > make your perl code faster: http://www.ccl4.org/~nick/P/Fast_Enough/ Dear ModPerl Lister, I have two questions: 1) In this list, I have seen folks asking general Perlish questions told to take their discussions elsewhere, along with the useless recommendation that they browse lists.perl.org - I have done this several times and joined a few of the lists, but only ever found lists that were rather beginner. I have also lurked in some of the groups.yahoo.com pearly lists without finding the right level. - can folks name any specific useful intermediate/advanced Perl lists? i.e. Perl 4+ years in a commercial env 2) I have one common approach to speed improvement that is not mentioned at all, to do with symbol table manipulation for functions, that I would like to polish via a list discussion - is this list appropriate for a thread discussing Perlish performance in general? I would guess that symbol table fiddles might be risky in a mod_perlish env. TIA Jeff
Re: When perl is not quite fast enough
Stas Bekman <[EMAIL PROTECTED]> writes: [...] > Me thinking to ask Nicolas to contribute these notes to our tutorial > section (http://perl.apache.org/docs/tutorials/) and if possible to > add some more meat to the original notes. If you remember our evil > plan was to host at perl.apache.org interesting tutorials, relevant to > mod_perl developers, but which are of interest to non-mod_perl > developers too, thus bringing them to our site and hopefully getting > them interested in mod_perl. Nicolas's doc, looks like a good bite ;) Great idea, Stas. His comments definitely should be part of the mod_perl canon; those notes present *the right approach* to optimization. -- Joe Schaefer
