----- Original Message ----- > From: Frank Barknecht <f...@footils.org> > To: "pd-list@iem.at" <pd-list@iem.at> > Cc: > Sent: Tuesday, November 6, 2012 6:19 AM > Subject: [PD] list vs. symbol array [was: Re: Licensing issues] > > On Mon, Nov 05, 2012 at 11:38:00AM -0800, Jonathan Wilkes wrote: >> ----- Original Message ----- >> > From: Frank Barknecht <f...@footils.org> >> > >> > On Mon, Nov 05, 2012 at 08:26:17AM -0800, Jonathan Wilkes wrote: >> >> How many table names total were there in the patch that was > overloading >> >> the device? >> > >> > I don't remember anymore, that was in 2009, when the abstraction > was first >> > posted here on pd-list. >> > >> > But if you don't believe me, just do some benchmarks on your own > and compare >> > array access with list filtering. >> >> It makes no difference if the number of table names is around 100. At 1000 > your >> method is certainly faster-- I've just never had a patch with 1000 > tables. > > I'm pretty sure, the patch at that time didn't either. The main problem > then > was the high frequency with which lookups had to happen. As a special election > day service I have written a benchmark showing this situation. On my machine > the symbolarray uses about 16 percent CPU at the "metro" period of > 0.01 ms > while list lookup uses 24. Now 0.01 ms may sound like a tempo you won't > encounter in real music, but that's wrong: In chords you play many notes at > the > same time, the "period" then is a very fast 0 ms. This can generate > CPU usage > spikes on slow devices if the lookup is too slow - at least that's my > explanation for why the symbolarray was able to fix the patch.
[symbolarray] does indeed take about half as much cpu as using the message box. It also takes exactly the same cpu as [makefilename %d-tab] which is much simpler and doesn't require an abstraction. But maybe you needed those specific names for the tables for some reason... A lot of these Pd vanilla prototypes suffer from already being at the very edge of what can be developed with the prototype. You can't easily[1] add a sort method, for example, nor can you extend the design to allow each element to be either a symbol or float without adding two fields to the template struct and a conditional that would impact the performance gain you get from using an array in the first place. Not to mention the near-complete lack of operators for symbols which is why I call it an array of Pet Rocks in this case. -Jonathan [1] You can certainly split symbols and count their length in Pd vanilla but it ain't pretty. > > Ciao > -- > Frank Barknecht _ ______footils.org__ > > _______________________________________________ > 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