Re^2: understanding devel::leak

The problem you are having is not a 'true' memory leak, i.e. the memory in fact is being freed. It just isn't being returned to the OS, but rather to Perl's own memory pool. Those two things are often confused. The difference is that if you'd run your while loop another time, it would not allocate another 90MB, but rather reuse the memory freed upon undef-ing the @X. If it were a memory leak in the sense that the rest of the thread is talking about, it'd eat up more and more memory, without you having a chance to reuse it (without exiting the interpreter).

Comment on Re^2: understanding devel::leak Select or Download Code

Replies are listed 'Best First'.
Re^3: understanding devel::leak by Nova (Novice) on Oct 05, 2007 at 15:57 UTC
Thank you for your responses and I apologize for the format problem in my previous post . From the point of view of the O/S , I can see that , once I have done work via my script which requires MEM , a large chunk of that MEM may no longer be available to the O/S for concurrently running apps . My perl app is running on WIN32 / ActiveState Perl 5.8.8 . Can I set any variables which would apply the -DPURIFY after Perl has already been compiled , or the binaries intalled . Further , while the script is running is there a variable which can be examined which I can use to monitor MEM usage . Kind regards, Nova .	[reply]
Re^4: understanding devel::leak by almut (Canon) on Oct 05, 2007 at 21:38 UTC
Can I set any variables which would apply the -DPURIFY after Perl has already been compiled Unfortunately not, it's a compile-time option only. You can read a bit more about this option and its primary use in perlhack, section External Tools for Debugging Perl. Also, I suspect you'd incur a noticable decrease in performance with -DPURIFY (even when not running under Purify, valgrind, etc.); in other words, it's probably a matter of trading speed for memory control... (I haven't done any benchmarking, though.) is there a variable which can be examined which I can use to monitor MEM usage That would definitely be a nifty feature, but I don't think such a variable exists. So, in addition to the respective system tools (like `top` on Unix — not sure what the best tool on Windows is), you might try the module GTop (based on `libgtop` from GNOME), but I don't know how well - if at all - that'd work on (native) Windows. Grepping through `libgtop`'s `configure` file produces a couple of hits in connection with Cygwin and MinGW, but that's about all I can tell...	[reply] [d/l] [select]
Re^5: understanding devel::leak by Nova (Novice) on Oct 07, 2007 at 01:07 UTC
Hi Almut , Thank you again for your thoughtful insights . I appreciate the points you have raised and will peruse the references you have included. In the past my apps ran on unix or linux machines , I have just recently begun testing some on windows machines , but the machines potentially have many other programs running on them , some quite MEM intensive , so I may have to be more innovative and careful about MEM usage and limits . Nova.	[reply]