[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [sc-dev] OSCFunc oneShot is breakable because of careless FunctionList implementation
On Wednesday, December 11, 2013 12:23:41 AM HKT, Julian Rohrhuber wrote:
On 10.12.2013, at 14:09, Scott Wilson <i@xxxxxxxxxxxxxx> wrote:
I agree that the most general and safe way would be to copy the
array. Although it creates a little bit of overhead, this is not
overly slow, and used in various places in the system.
Benchmarking shows that "array.copy.collect" cuts performance in about half
(though, somewhat to my surprise, it's actually slightly faster than the
approach in the patch, probably because of the extra dispatch into
prCleanup).
a = FunctionList([{ 0 }, { 1 }]);
x = Array.fill(20, { bench({ 100000.do(a) }, false) });
[x.minItem, x.maxItem, x.mean, x.median]
I ran the test three times, with different versions of FunctionList:
// original: [ 0.50689816474915, 0.90126800537109, 0.66438055038452,
0.51259994506836 ]
The code as it is now in master (with the bug). 0.9 sec seems to be an
outlier, according to the mean and median.
// .copy: [ 0.92937803268433, 0.94970107078552, 0.9445198059082,
0.94484353065491 ]
Using "array.copy.collect," execution pretty consistently takes
approximately 9/5 times longer.
// deferred: [ 0.9169819355011, 0.96520686149597, 0.94811583757401,
0.94869446754456 ]
Using the "evaluating" flag and a delayed removal, execution time varies
more but average is very slightly worse than the copy approach. Probably
that is not statistically significant.
The test doesn't compare performance when a function is actually being
removed from the list. My performance concern is about the normal case
(where the function list doesn't modify itself). I don't know if we can
predict a reasonable maximum rate of incoming OSC. For example, if it's an
ensemble piece for 10 TouchOSC mobile controllers feeding into one
computer, all with the accelerometer enabled, you would get several
thousand OSC messages coming in per second.
It may be "rare" to have multiple responders for the same message path, but
I don't think you can predict that either. A reasonable OOP design for the
above case would be an object that handles incoming traffic from one
controller (one IP address), each adding its own OSCFunc. In that case, you
would have a FunctionList being evaluated thousands of times a second. (You
could optimize that by one OSC receiver object that forwards messages to
other objects based on the integer representation of the IP address.)
I'm not quite satisfied with a performance hit of nearly a factor of 2. I
wonder if there's a faster way. (If there is no faster way, I'd be in favor
of stable, reliable behavior rather than the current behavior.)
hjh
_______________________________________________
sc-dev mailing list
info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: https://listarc.bham.ac.uk/marchives/sc-dev/
search: https://listarc.bham.ac.uk/lists/sc-dev/search/