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