Tels <[EMAIL PROTECTED]> writes:
> -----BEGIN PGP SIGNED MESSAGE-----
>
> Moin,
>
> On 05-Oct-02 [EMAIL PROTECTED] carved into stone:
> > En op 5 oktober 2002 sprak Ann Barcomb:
> >> I hadn't looked in to how I could solve my question, and because
> >> it was given to me as a low priority task, I wasn't sure I was going
> >> to have a chance to either. But you can count me as someone who will
> >> be very happy about the module :)
> >
> > I noticed CPAN Proc::ProcessTable, which is worth a look, if only
> > to peer at the code and note the portability, er, challenges.
> > If the module that reports memory usage itself consumes significant
> > memory, that is a pest when trying to figure out how much memory
>
> > a Perl data structure is using. That is the nice thing about
> > Merijn's original sbrk() -- it is lightweight in the extreme.
>
> Yes, but more or less useless, since:
>
> * your system might not have it, so you either get nothing, or something
> incompatible (depending on how it is implemented, or not) in Devel::MemUses
> * it doesn't reflect the true usage of a perl structure anyway, it just
> reports a change in the heap, which might or might not be related.
With "usage of a perl structure", do you mean the size of an SV, plus
the size of an XPV, plus the malloced area for the string, etc.? I
think the heap usage is more important, because these is the memory
taken from the system and not useable for other processes.
> sbrk *might* be usefull to someone, but I wouldn't use it to find out how
> much memory a perl structure consumes - the numbers may well be totally
> wrong. So, I wouldn't use it (part of that is that I didn't understand the
> man page of sbrk() - which means I would likely interepret the results
> wrong)
>
> (I mean, come on:
>
> Calling sbrk with an increment of 0 can be used
> to find the current location of the program break.
>
> Thats gibberish to the average perl programmer like me. It's probably not
> meaning that the program had a KitKat break and we are trying to locate
> it via it's breadcrumb trail...)
>
> As for ProcessTable, that sounds like a good idea, since looking at top's
> output is cumbersome.
>
> Also, you could (probably) do something like:
>
> #!/usr/bin/perl -w
>
> use Proc::Memory 'report';
>
> report(); # baseline
> require Math::BigInt; Math::BigInt->import();
> report(); # and now?
>
> So you get it in one go (assuming the (nonyetexistant?) Proc::Memory is
> lightwight :)
>
I assume we need both --- a raw, lightweight interface with sbrk() and
some more user-friendly interface (probably using my currmem()
function and/or Proc::ProcessTable), but which is probably more
inaccurate (because of Heisenberg).
Regards,
Slaven
--
Slaven Rezic - [EMAIL PROTECTED]
tkrevdiff - graphical display of diffs between revisions (RCS or CVS)
http://ptktools.sourceforge.net/#tkrevdiff
