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. 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 :) On Tue, Mar 1, 2011 at 12:55 AM, Alastair Leith <[email protected]>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*<http://www.brainyquote.com/quotes/quotes/a/antoinedes131176.html> > * * > > 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 > <[email protected]>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*<http://www.brainyquote.com/quotes/quotes/a/antoinedes131176.html> >> * * >> >> >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Quartzcomposer-dev mailing list ([email protected]) >> Help/Unsubscribe/Update your Subscription: >> >> http://lists.apple.com/mailman/options/quartzcomposer-dev/jonathan.hart%40gmail.com >> >> This email sent to [email protected] >> > > >
_______________________________________________ Do not post admin requests to the list. They will be ignored. Quartzcomposer-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/quartzcomposer-dev/archive%40mail-archive.com This email sent to [email protected]
