[PD] RAM usage (Pd-0.38.4-extended-RC7 & cyclone)

Mathieu Bouchard matju at artengine.ca
Tue Jan 24 08:01:47 CET 2006


On Mon, 23 Jan 2006, Martin Peach wrote:
> Mathieu Bouchard wrote:
> > On Mon, 23 Jan 2006, Martin Peach wrote:
> > > Mathieu Bouchard wrote:
> > > > and then how much RAM do they take once loaded? e.g. on Linux the
> > > > RAM it's reported (by /proc/$$/maps) to take is 8k (plus one
> > > > filehandle), that is
> > > One thing I noticed while doing this is that pd (or is it the OS?)
> > > doesn't free memory when objects are deleted from a patch.
> > I was more interested in space taken by a class than by an object...
> Oooh my brain hurts! What namespace are we in? I assume a class is the code
> that is loaded to implement an external (the .dll or .pd_linux) and the object
> is just the struct particular to one instance of the class (or is it the other
> way round?).

Yeah it is. Often in the Pd world, the words "class" and "object" get
confused, but I'd rather have standard OOP terminology used in the Pd
world. I wanted to know what's the amount of RAM used up by a .dll file
once loaded in RAM. I ask because I know that in Linux, the amount of RAM
taken by a .so file once loaded in RAM is more than the length of the file
due both to paging issues and to "fixup" issues (basically the table used
for dlsym() which is used for relocating pointers considering that RAM
positions can't be hardcoded in a .so)

There's also the actual t_class allocation but that's very small compared
to any .so ... Now that I think of it, a t_class also owns several smaller
structures, and while I'm sort of curious about how much RAM it takes,
chances are it doesn't vary much from OS to OS.

> If this is the case they should both show up as extra memory allocated
> to the pd process, the struct being a relatively trivial amount of that
> memory. (of course I'm probably wrong here again ;()

a t_object (aka t_text is 7 words. Here by word I mean the size of an
ordinary data pointer. That's 28 bytes in 32-bit mode and 56 bytes in
64-bit mode. But that's really not all. Every t_inlet is 7 words as well.  
Every t_outlet is 4 words. Each of those things is allocated separately.
Every allocation requires at least an extra word for use by malloc/free,
and sometimes several extra words.

The fact that a Pd object is broken down in all of those little structs
doesn't do any good to the cache, as it must keep lots of different parts
of RAM together in order for the CPU/Pd to do anything. That is likely to
matter a lot more than the total usage of RAM these days, but then, I 
haven't benchmarked it lately.

 _ _ __ ___ _____ ________ _____________ _____________________ ...
| Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju
| Freelance Digital Arts Engineer, Montréal QC Canada




More information about the Pd-list mailing list