in reply to Re: Re: BEGIN initialization and memory
in thread BEGIN initialization and memory

one note though, in your example you are allocating one huge block, in most live programs they dont presize arrays or hashes and end up growing them with a loop. in those cases the memory will most likly never be released. So in most cases it is safe to think about the memory, once allocated, being stuck allocated to your running program.

-Waswas
  • Comment on Re: Re: Re: BEGIN initialization and memory

Replies are listed 'Best First'.
Re: Re: Re: Re: BEGIN initialization and memory
by BrowserUk (Patriarch) on Jul 24, 2003 at 02:35 UTC

    Agreed its a clumsy demonstration. However, I have seen the memory returned in more realistic situations. For example, if you copy a large array when sorting it

    my @a = 1 .. 100000; @a = sort{ $b <=> $a } @a;

    When I run this code, I can watch the memory usage peak at around 21 MB, but then fallback to around 18 MB. So even in this fairly simple and common operation, some memory is being returned to the OS. Not all of it, as loading the array only consumes around 8 MB, so the post sort figure of 18 shows that a considerable amount of "working storage" hasn't been returned to the OS. If you then empty the array @a = ();, another 3 or 4 MB is released. Interestingly, if you then undef @a; another 1 MB or so is released. Skipping the null list assignment step takes you straight to the (same) final position.

    It would be a labour of love to try and understand what and when this occurs enough to be able to reliably make use of the information, so the your basic point about essentially ignoring it probably sage advice in most situations.


    Examine what is said, not who speaks.
    "Efficiency is intelligent laziness." -David Dunham
    "When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller