On Nov 7, 2012, at 8:49 PM, [email protected] wrote: > From: Jonathan Wilkes <[email protected]> > Subject: Re: [PD] list vs. symbol array [was: Re: Licensing issues] > Date: November 7, 2012 8:45:49 PM EST > To: Frank Barknecht <[email protected]>, "[email protected]" <[email protected]> > Reply-To: Jonathan Wilkes <[email protected]> > > > ----- Original Message ----- > >> From: Frank Barknecht <[email protected]> >> To: "[email protected]" <[email protected]> >> Cc: >> Sent: Tuesday, November 6, 2012 6:19 AM >> Subject: [PD] list vs. symbol array [was: Re: Licensing issues] >> >> 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
I didn't mean to bring up an externals vs vanilla debate. We obviously use what's best for the situation. I'm choosing to work more in vanilla land because I simply can't include some externals in my app. Plus, I know those patches will *just work* for everyone. We'll see in practice if this works, but I'd much rather avoid coding custom externals for this project. Also, does anyone know what cyclone's license is? I can't find the current version in the svn, but the old zip on the website has a BSD-like license. Having [coll] and [seq] would be very useful. It'd be nice to see these in vanilla at some point ... why reinvent the wheel? > [1] You can certainly split symbols and count their length in Pd vanilla but > it ain't > pretty. [list-sort] in list-abs. -------- Dan Wilcox danomatika.com robotcowboy.com
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
