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

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

  • Comment on Re: Re: Re: Finding the size of a variable

Replies are listed 'Best First'.
Re: Re: Re: Re: Finding the size of a variable
by Elian (Parson) on Nov 11, 2002 at 19:56 UTC
    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... :)

      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

        Oh, I dunno, it doesn't take that long. And unfortunately it's the only really effective way to see how much memory's currently in use, though even then there are some interesting bits to deal with.

        Also, don't forget that Devel::Profiler is pure perl, and thus has a fair amount of overhead. Devel::Size is entirely in C, and a fair amount faster. I'd guess we'd see about a factor of 100 speedup over a perl version, but it might be upwards of 200 to 300 times faster for what it does, as well as immune to a lot of the problems you'd find doing this in perl. (It's not tripped up by tying or overloading, for example)