in reply to Re^6: Memory management
in thread Memory management

Have fun! The memory effect showed up pretty clearly when I made the array big enough. BTW, what graphics drawing packages have you been having success with? I've got some requirements for things along those lines.

One of the reasons to "hold onto memory" once you get it is that the OS memory allocator is "expensive" in terms of CPU. Often when making a memory region allocated to you either bigger or smaller, the OS will get another contiguous hunk of the right "new size" and then copy all the old stuff into the new area! All this copying around can get really expensive! Perl has to do extra work to keep track of memory management, but at the end of the day this works out to be very much more performance efficient. I've run some tests in C with gcc on my WinXP platform to just to experiment with this although I don't think it appropriate to post C code here. But Perl is written in C and will be making all the same malloc(),calloc(),realloc() type memory calls.

Replies are listed 'Best First'.
Re^8: Memory management
by desemondo (Hermit) on Aug 20, 2009 at 10:04 UTC
    cheers for that - I gave it a try and definitely could see the memory footprint growing, but once it had completed one cycle of the loop it didn't grow any further. Is that what I should expect to see with that script?

    From what I gather - this makes sense. Like you say, if the OS kept having to allocate and reallocate memory it would slow things down a lot...

    So far I've been playing around with GD::graph, in particular gd::graph::line. Sometimes its a bit limiting, but overall its done very well. I use it a lot for analysing some of my systems at work, primarily things like throughput and latency, etc.

    Are you familar with .Net? Some of the guys at work have been getting into the .net charts - I'd love it if someone created an interface for perl for something like these. dotnet_graphs