Code just taking up more memory does not necessarily mean you've got a memory leak*. It may be that the algorithm chosen just takes up more memory while it's working, or that your code is inefficiently structured - i.e. you're keeping a lot of variables around that you don't need instead of using simple blocks/subroutines that automatically destroy unused variables.
* IMO, a memory leak is what happens when you've got memory allocated that is *unreachable*. Perl is reasonably good at detecting and clearing those, except for circular references. If that's what you're trying to detect, you may want to take a look at Test::Memory::Cycle (note: I've never used it myself)
| [reply] |
Well the leak is obviously on line 13054. Or maybe 13053. Somewhere around there, at any rate.
A reading of How (Not) To Ask A Question and heeding the advice might produce more cogent help.
| [reply] |
Ask your boss (or whoever it was that asked you to "detect" the leak), why he selected you, a Perl newcomer, to find it.
If you don't know Perl, how are you expected to find a memory leak?
| [reply]
[d/l]
[select] |
Why bother? Memory is cheap, just add lots and lots of memory to that machine and the memory leak problem will soon become insignificant.
CountZero A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James
| [reply] |