Just a guess... maybe allocating all that memory is forcing the OS to page other apps out. (I'm not sure how much memory is getting used but if it's more than 1/4 of the system total it's possible that is slowing stuff down.)
cheers Miller On Mon, Jan 28, 2008 at 04:52:56PM +0100, matteo sisti sette wrote: > Hi, > > Suppose I create a [sample] abstraction that basically contains a > [table] to store a sound sample, and a [soundfiler] to read it from a > file. > > One of the reasons for creating such a "trivial" abstraction is that > it has a GOP GUI with > -a symbolbox where you can write and see the filename > -a test button that plays the sample. > > Now suppose the test part is implemented like this (simplified): > > [r $1-test] > | > [tabplay~ $1] > | > [throw~ sampletestout] > > > ($1 is the name of the sample, i.e. the name of the table, and the GUI > is supposed to have a bng sending to $1-test) > > Obviously, to avoid unnecessary cpu-usage, that would become enormous > if I have many sample instances, I will include the necessary patching > in the abstraction in order to [switch~] it on only when playing, and > off when not. Usually you'll be testing at most one sample at the same > time. > > Now the question is: in case there are N [sample]s in my patch, > Is it possible that the time needed to load ONE sample (sending a > [read...( message to the [soundfiler]) increases with N??? > If so, why? > > The fact is that I have been using such an abstraction very much, and > have a great number of [sample]s in my patch, and started to notice > that loading all the samples was terribly slow. > Then, without thinking it had any relation to this, I realised I could > easily remove all the "~" part from the sample abstraction, by > implementing a unique [sampletester] and having [sample]s sending him > messages to test one sample. > I did this, and removed the [tabplay~] thing from the [sample] > abstraction, and now the loading of samples seems to be enormously > faster... > > > > -- > Matteo Sisti Sette > [EMAIL PROTECTED] > http://www.matteosistisette.com > > _______________________________________________ > PD-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list _______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list