[PD] list vs. symbol array [was: Re: Licensing issues]

[Jonathan Wilkes]

----- Original Message -----

> From: Frank Barknecht <fbar at footils.org>
> To: "pd-list at iem.at" <pd-list at 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 <fbar at 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 at iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> http://lists.puredata.info/listinfo/pd-list
>