Le 2011-09-29 à 10:17:00, Jonathan Wilkes a écrit :

Since you have a large patch, I'd be curious to know how much memory is taken up by having the switched off voices just sitting there.

It's not easy to know how much memory is taken by a bunch of small mallocs. If you use getbytes() you have some idea of what's going on, but it doesn't count the malloc accounting info that only malloc()/free() usually know about, and it doesn't count the overallocation that malloc() might do in order to make its life easier and make gradual realloc() faster. Then it also doesn't count the overallocation of the memory zones so that brk() or mmap() or mremap() doesn't have to be called as often, which means that when you look at the process size in a process monitor (ps or top or other) the difference you might see will not be accurate at all... even if you manage to get it in bytes 4k-blocks instead of megabytes.

So, if you really want to know the memory usage for a certain part of pd, make sure that everything uses getbytes() instead of malloc()/new/etc, and then try to find a formula that can tell you how much extra you should count, and call it from getbytes() and freebytes() in order to keep accurate statistics.

E.g. I recall that will the Perl Allocator that was being used by Perl in the late 90's, you had to add sizeof(void*) to your byte request, and then round to the next power of two. From this info you can then write :

size_t real_size (size_t n) {return 1<<highest_bit(n+sizeof(void *));}

highest_bit is a function that finds the position of the highest «1» bit of an int. I have such a function in gridflow.h :

#define Z(N) if ((x>>N)&(((typeof(x))1<<N)-1)) { x>>=N; i+=N; }
static int highest_bit(uint32 x) {int i=0; Z(16)Z(8)Z(4)Z(2)Z(1)return i;}
#undef Z

 ______________________________________________________________________
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Reply via email to