perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Perrin Harkins <per...@elem.com>
Subject Re: Loading at startup to use shared memory
Date Tue, 07 Nov 2006 18:03:46 GMT
On Tue, 2006-11-07 at 11:35 -0500, Jonathan Vanasco wrote:
> some tips:

I think some of these are a little over-zealous, Jonathan.

> 			but things like File::Find eat up a TON of memory ( 2+ mb ), and  
> most functionality can be coded in 10-15 minutes.  ( vs 2 minutes if  
> you use the module )

There are always trade-offs when using CPAN modules, but when in doubt,
it's a good idea to use them first and then make changes later after
your code is working, if your tests show that one of them is a memory
hog.  File system traversal always sounds easier than it really is, as
is often the case with commonly used CPAN modules.

> 	use all of your internal code with constants for debugging, not  
> variables
> 		if ( DEBUG__ ) { }	is optimized away
> 		if ( $DEBUG__ ) {} is not
> 		if you want to use variables, wrap them in a constant
> 			if ( DEBUG ) {
> 				if ( $DEBUG__ ) {}
> 			}
> 		your dev machine takes a hit on performance with this approach, but  
> your production machine is way leaner ( 30-40% less opcodes and  
> memory ) than the standard $DEBUG methods

Your debug statements take up 40% of your memory?  I don't think that
will be the case for most people.  I hardly ever use perl's
pseudo-constants.  They're more trouble than they're worth, and most
apps will not show a significant difference in performance.  This is
only worth thinking about if you have huge amounts of debugging
statements in your code (in which case, maybe you should try using the
debugger instead).

> 	Note that DBI and some other modules do caching.
> 		DBI caches db handles and statement handles internally.

Usually you tell it to do this for performance reasons, by using
Apache::DBI or DBI->connect_cached and prepare_cached.

- Perrin


Mime
View raw message