Subject: Re: [PD] list vs. symbol array [was: Re: Licensing issues]
Date: November 7, 2012 8:45:49 PM EST
----- Original Message -----
From: Frank Barknecht <fbar@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]
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.