Memory is supposted to be freed once the variable is out of scope and there are no more references to that data element. So in your example above, while the memory that $ref points to will continue to live outside of sub a, %copy and $ptr will not. Now if you returned, say "return \%copy;", and assigned a variable that value in the main part of the program, %copy's data will remain around even though %copy itself is no longer defined in it's block, until that new variable is to go out of scope.
With my experience with mod_perl is that you improve performance by avoiding having those large arrays and hashes which are mutable in memory, and use some sort of 'disk paging' system, whether that be through flat files, a DB, or some other means. The only data that should be persistent in a mod_perl script in order to avoid untamed memory growth are static, unchanging variables. As you've got it, it seems that you're trying to copy a hash often enough, and that might be causing a memory growth. This definitely sounds like you've got handing references to your various copies of that hash, and thus increasing the memory space. Is copying the hash necessary? This is probably the first question to ask, as PSI::ESP tells me that there's probably a better way to do it. Also, unrelated, but I've found that the module Clone is better to do any necessary duplication of non-scalar values, as opposed to trying to coerce references to work that way, particularly when they get into nested structures.
In reply to Re: A question of memory, mod_perl, and references and subroutines
by Masem
in thread A question of memory, mod_perl, and references and subroutines
by Yohimbe
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |