On Thu, 3 Feb 2011, Roman Haefeli wrote:
In your situation I'd try to do everything that doesn't necessarily need to happen in 0 logical time to extend to > 0 logical time. Unless you really need the new tables immediately after the buffer was filled, I'd suggest to copy them over 'slowly'.
BTW, merely creating a table is taking a lot of time, especially as the table's a_vec is allocated using getbytes(), and getbytes() takes the time to fill the whole 300000*4 bytes (or 300000*8 bytes) with carefully polished zeroes.
In addition, OSX's allocator for large chunks of memory does a mmap() just on linux, but unlike on linux, mmapping new memory on osx is annoyingly slow (perhaps also another kind of zero-polishing). However, I can't tell you whether this happens at the time of mmap(), or at the time of starting to write in a new page of RAM (a 4k block), but this does not matter, as getbytes() forces all pages to spring into existence at the same time.
One approach once mentioned by Miller Puckette is to do array copying by doing it in the audio domain within an upsampled sub-patch. This would make DSP drop-outs during array copying much less likely.
The table is still being cleared anyway, once or twice, before it's filled with the real content, and it uses up that much of space in the SRAM too (cache). This happens every time you create or resize an array.
_______________________________________________________________________ | 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
