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
_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
