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
