Issac Goldstand wrote: > Ah yes, but don't forget that to get this speed, you are sacrificing > memory. You now have another locally scoped variable for perl to keep > track of, which increases memory usage and general overhead (allocation > and garbage collection). Now, those, too, are insignificant with one > use, but the significance will probably rise with the speed gain as you > use these techniques more often...
Yes, I know. But from the benchmark you can probably have an idea whether the 'caching' is worth the speedup (given that the benchmark is similar to your case). For example it depends on how many times you need to use the cache. And how big is the value. e.g. may be caching $foo->bar doesn't worth it, but what about $foo->bar->baz? or if you have a deeply nested hash and you need to work with only a part of subtree, do you grab a reference to this sub-tree node and work it or do you keep on dereferencing all the way up to the root on every call? But personally I still didn't decide which one is better and every time I'm in a similar situation, I'm never sure which way to take, to cache or not to cache. But that's the cool thing about Perl, it keeps you on your toes all the time (if you want to :). BTW, if somebody has interesting reasonings for using one technique versus the other performance-wise (speed+memory), please share them. This project's idea is to give stright numbers for some definitely bad coding practices (e.g. map() in the void context), and things which vary a lot depending on the context, but are interesting to think about (e.g. the last example of caching the result of ref() or a method call) _____________________________________________________________________ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
