"be consistent" | |
PerlMonks |
Re: Conditional Interpretation?by earcam (Initiate) |
on Feb 01, 2006 at 23:40 UTC ( [id://527193]=note: print w/replies, xml ) | Need Help?? |
Thanks for all suggestions, I will investigate these further and report back.
To clarify my problem here's an example
Replaced with something like: With the shebang in calling script stating something like: #!/usr/bin/perl -Wall -POD_PERL_INCLUDE to include the POD section. The instantiation check exists in every object/instance method (with a similar check for class-only methods) - with a massive number of subroutine calls, this really hits performance across all the code. ( I know there's quicker ways of checking correct instantiation, but it's still a check that becomes unnecessary for production code ) There are many other checks that could also be excluded. Our logging already works using sub refs to a dummy subroutine to avoid endless if($obj->{'DEBUG'}){ ... } calls so no gains to be made there. I think we may have exhausted the majority of optimisation tricks - avoiding these kind of checks shaves off approximately 1/4 of the total run time. I found this (via "man perlbot") 1 Do not attempt to verify the type of $self. That'll break if the class is inherited, when the type of $self is valid but its pack- age isn't what you expect. See rule 5. 2 If an object-oriented (OO) or indirect-object (IO) syntax was used, then the object is probably the correct type and there's no need to become paranoid about it. Perl isn't a paranoid language anyway. If people subvert the OO or IO syntax then they probably know what they're doing and you should let them do it. See rule 1. Though object orientated, we've avoided inheritance, but I still disagree with the above because not checking how a method is called has already caused hours of scratched heads and bug hunting - so we do need these checks at dev level, but only at dev... Thanks for all comments. cheers, Caspar
In Section
Seekers of Perl Wisdom
|
|