On 01/03/2011, at 8:26 PM, Jonathan Hart wrote:
I can't really say what's fastest without doing benchmarking for vs
for each is a classic performance gotcha in interpretive languages.
I'd try out a classic for loop and see if you get incremental gains.
You probably will, but dont be surprised if its not much.
Is there a reason you are mixing and matching 2d arrays with 1d
arrays of ints? Seems like these should be normalized into a unified
data type, even if it means lots of arrays with a single item.
BTW This wouldnt be that hard to do in an Obj C patch. Not that Obj
C patches are a walk in the park, but its relatively simple stuff
you're doing and you could easily combine the patches.
Is it fairly easy to wrap C code inside a QC Plugin Cocoa template?
The Cocoa lexical and syntax stuff is foreign to me.
The first patch is just to generate unit-test data. It's not
indicative of anything specific. I sort of decided independently, to
fix to 1D and 2D as separate JS scripts, just to save headaches and
hopefully optimise. I was interested in a one size fits all approach.
This is all for a JS patch that smoothes values using the math
equations associated with the conventional Smooth patch.
It gives nicer curves than the Music Visualiser JS smooth patch which
is 'procrastinative', in that the values ramp down as they approach
destination (sort of inversely to delta). It doesn't look to good
compared to the usual equations. Being on Leopard I can't put a Smooth
patch inside an iterator and publish an array :/
The chief question with this demo was only to do with the second JS
patch.
Essentially if the array lengths are the same, neither of the two if
statement code blocks execute. So why is performance so slow for
essentially two calls to .length method and an integer difference
calculation and two if statements that evaluate to false. It should be
relatively quick to do that, no?
I'm sure Chris could chime in but I would imagine Apple's stance on
the JS patch would be that its meant for rapid prototyping, not lean
mean production code...
PS - if this is getting to JS oriented and too off topic for the
list, please let me know and I'll take it offline :)
Ditto.
On Tue, Mar 1, 2011 at 12:55 AM, Alastair Leith <qc.student...@gmail.com
> wrote:
Thanks Jonathan
Every time I write a line of code in JS I'm wondering 'is this
method faster than some other way' (hand coding in a loop instead
of .slice or whatever). I never stop wondering about those things.
Sending calculations to functions instead of inline, nested
functions instead of
I think I find C syntax more direct than JS (novice-intermediate at
both). It's high time I learned enough Cocoa to wrap some C code
into a plugin to do these kind of number crunching things. Or got
new metal to run OpenCL which sounds kinda risky itself.
Thanks for tip of typeof statement. What's risky about nested loops?
Risky as in potentially slow? Are for (k in me) {} loops any slower
than for (i=0; i<length; i++) {} loops for example?
Best
Alastair
The machine does not isolate man from the great problems of nature
but plunges him more deeply into them.
Antoine de Saint-Exupery
On 01/03/2011, at 7:24 PM, Jonathan Hart wrote:
I'm not a guru on JS performance in QC, but here's my 2 cents...
Your first Javascript patch you're doing a lot of risky stuff such
as typeof and nested for loops.
Your second JS patch is doing more risky stuff.. like array
slicing. These can be notoriously slow operations depending on the
JIT being used.
Keep in mind interpreted languages such as Javascript are at the
mercy of their JIT compilers and each one has its performance
quirks when handling things like loops and especially untyped
operations (like typeof and untyped array operations like slice).
You are also inputting and outputting entire structures, which may
be slow even with smaller lengths, depending on how QC passes these
things in and out of the JS.
One of the downsides to untyped languages like JS. You trade off
performance for easy syntax.
Jonathan
On Tue, Mar 1, 2011 at 12:15 AM, Alastair Leith <qc.student...@gmail.com
> wrote:
Hi Christopher,
This example I have two JS patches. The first just flip-flops b/w
two Arrays of n and n/2 elements. It only takes CPU when changing
state.
The second patch modifies it's output to match the length of the
input Array. First it compares .length of the Arrays, if same do
nothing.
Although it's actually written if (a<b) {lose elements}; if (a>b)
{add elements}, where a is input and b is internal JS array.
So maybe some kind of if (a == b) break_statement(?); is required
Anyhow without a Time input forcing execution every frame it runs
60fps even on my old box but with execution every frame it crawls
to 5fps at n=2000
Best
Alastair
The machine does not isolate man from the great problems of nature
but plunges him more deeply into them.
Antoine de Saint-Exupery
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Quartzcomposer-dev mailing list (Quartzcomposer-dev@lists.apple.com
)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/quartzcomposer-dev/jonathan.hart%40gmail.com
This email sent to jonathan.h...@gmail.com
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Quartzcomposer-dev mailing list (Quartzcomposer-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/quartzcomposer-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
