On Tue, 30 Aug 2011, IOhannes m zmoelnig wrote:
why not simply resize the internal array as needed, starting with 32 elements and doubling whenever the limit is reached?
binbuf could be used for that, if the libc's realloc does in effect the same thing. i think that this is the case with modern glibc (Linux/CygWin) as well as Perl's allocator (when I looked at it 10 years ago), but not necessarily other libc implementations (FreeBSD/OSX, Google, Microsoft) that I didn't try it with, so if anyone could check, that would be interesting.
To test that, add millions of atoms to a binbuf and see how much time it takes. A «bad» implementation will roughly quadruple the time each time you double the number individual additions, whereas a «good» one will just double the time.
But in «bad» implementations, the assumption was that the user of realloc was responsible to manage extra preallocations such that the buffer wouldn't switch places often... it's not really bad, just inconvenient.
I think that those facts are not very well known... perhaps poorly advertised. People porting Pd would have an interest in benchmarking some parts of pd in case they assume too much about realloc on non-glibc platforms.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC