in reply to Re: Finding the size of a variable
in thread Finding the size of a variable

Try building with perl's malloc and -DDEBUGGING enabled. Ilya's wedged an amazing amount of tracking data into that memory allocator. Probably not quite enough to do what you want, but it's close. Unfortunately anything you might want to do will definitely require a custom perl, as you'd need to override the allocation and free routines. (This module has the advantage of being able to work standaline, as it doesn't have to intercept anything)

Replies are listed 'Best First'.
Re: Re: Re: Finding the size of a variable
by samtregar (Abbot) on Nov 11, 2002 at 19:43 UTC
    Thanks, I'll try that. While awaiting your reply I had a minor brainstorm on how to build it. I could augment Devel::DProf (and/or my baby, Devel::Profiler) to capture the value of Devel::Size::total_size() at each data point. Use that to develop total memory allocation profiles for each subroutine. This would probably be effective at catching really large allocations, but it will likely miss small ones due to Perl's use of SV arenas, right?

    UPDATE: I'm dumb. I jumped to the wrong conclusion that Devel::Size::total_size() returned the total amount of allocated memory for Perl. RTFM, sam.

    -sam

[reply]
      Oh, OK, I see. Hrm. Well, potentially, if the CV tracing worked properly, you could just do a total_size(\%main::); and watch the changes, as there's very little not findable from there. (Some of perl's internal structs are about it)

      Might be just a little CPU-intensive, though... :)

[reply]
[d/l]
        I think walking the entire symbol table on every subroutine call is basically non-feasible. Devel::Profiler does it as startup and it takes a long time for large programs.

        I'm looking at the possibility of using GTop or Proc::ProcessTable to do the checking. There are some definite drawbacks, but it might still work to find largish memory leaks.

        -sam

[reply]

In Section Meditations