Tels <[EMAIL PROTECTED]> writes:
> Moin,
>
> On 05-Oct-02 Slaven Rezic carved into stone:
> > 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
>
> Yes, that is what I thought.
>
> > think the heap usage is more important, because these is the memory
> > taken from the system and not useable for other processes.
>
> But shouldn't that be just the same, or slightly more (if the memory is
> used in chunks of, let's say 16 bytes, it might alloc up to 15 more).?
The malloc system will probably get larger chunks from the underlying
virtual memory system (4K or 8K or so). Malloc itself will use smaller
chunks (e.g. FreeBSD and glibc malloc use 16 bytes, I think perl's
mymalloc uses even smaller chunks).
That's fine, but memory gets fragmented. Suppose you make a large
1000000 byte malloc, then a 1 byte malloc, and finally free the large
malloc'ed area. The process' memory usage will still be the same,
because the malloc system can't give the large area back to the
virtual memory system. This is only possible if the freed area is at
the end of the heap.
Somewhere in this thread I said that glibc's malloc is cool because it
uses mmap() for large memory chunks. In this case, the large chunk
won't be allocated on the heap, and after freeing the large chunk the
memory may be returned to the system.
> Or did I understand something wrong?
>
> Nevertheless, making your data structures smaller will help, even if in
> some particulare case it doesn't reduce the heap usage directly.
And tuning the malloc system may also help.
> Also, comparing how much mem an array if SVs takes to a string etc would be
> very usefull (for me).
>
> Cheers,
>
> Tels
>
Regards,
Slaven
--
Slaven Rezic - [EMAIL PROTECTED]
babybike - routeplanner for cyclists in Berlin
handheld (e.g. Compaq iPAQ with Linux) version of bbbike
http://bbbike.sourceforge.net
