Managing Macros patches inputs...

yanomano's picture

I answer myself, always to speed up rendering... What is better for FPS : Publishing a lot of inputs from macros patches to the root one or manage values inside a big structure in destination to macros Patches. About the differents levels of a composition: Is it better to explode a big structure into several ones ? One structure for each level of the composition for exemple.... (So we are not going to travel certain members in levels where they are not needed ? ) What about Structure index member patches ? Are they FPS consuming ?

Are structures with keynamed index much heavies ?

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

cwright's picture
profile

This one could go either way -- it depends on the amount of data being passed around.

Index member patches are probably a bit faster than key member patches, but either way it's probably a very small cost compared to the rendering patches.

Several structures probably isn't better -- passing unused values to levels where they aren't needed costs nothing, so keeping them together is probably best.

(CompSci nerd disclaimer: Having larger structures may make lookup's (by index or key) take longer, depending on their implementation, but have a small per-frame baseline CPU expense. Having several structures raises the baseline amount of processing per frame, but may make for faster lookups Depending On Their Implementation. I think structures are backed by NSArrays (fast for index) and NSDictionaries (fast for keys, since they're hashed), so my Completely unscientific speculation is that large structures will have a lower overall cost, and a similar lookup cost compared to several smaller structures. This could be completely wrong, but it's my hunch.)

yanomano's picture
it is good to learn...

Thanks for the reply, very clear as usual ! I like to know that "passing unused values to levels where they aren't needed costs nothing"...it's a very good start point. I was espected too that "Index member patches are probably a bit faster than key member patches". I try to catch the "very small cost" because i think, it became rapidly big in iterators or other....And small+small+small= a little big I start to love structures because they make managing spaguettis and nested patches easy, and you can retrieve variables everywhere in the composition.

Do you think it is a good way to generalise this method : Structure VS a lot of published values from Macro Patches?

toneburst's picture
Structs

I've also recently discovered the joy of using structures to pass around control values in QC. The Spooky Send and Receive patches are also very nice for minimising cable spaghetti, especially if you feed them structures.

alx

Quartz Composer Blog: http://machinesdontcare.wordpress.com

Music Site: http://www.toneburst.net

cwright's picture
danger

Be careful spending too much time fixing the "very small cost" parts -- smokris and I spent a large amount of time profiling and optimizing patches at WWDC (there were a few great sessions on how to use various tools to get the necessary info for this). We found that "very small cost" pieces are usually just that: very small. Making something 10% faster that only takes 5% of your time makes it just 0.5% faster overall. Meanwhile, making the heavy 50% part 10% faster makes it 5% faster overall. Much better use of time, honestly.

(I know where you're coming from -- I'm also a "make the tiny stuff very fast!" kind of person, but I've since found better ways to make things fast)

yanomano's picture
No Adventures without danger :)

Thanks very much for this advice Christopher, I think that I see what you mean....

It seems that with GPUand CPU , things are not linear, sometimes you add a little patch and it kill everything. So I try now to understand what's happen behind the patches to assemble compositions with better method. In this way, I learn lot of things from people like you with a rigorous (but very fun :) developer approach...I hope this is not pathologic, but just a wish to keep the tools I try to design snappy and efficient....:)

tobyspark's picture
profiling how-to

something i'd really like to see is an in-depth tutorial/explanation on profiling qc comps. same for real-world debugging and profiling of custom patches.

...its one thing to make something that works, another to understand why the frame rate is 4fps =]

toby

psonice's picture
profiling

I'd like that too. Not just custom patches though - is there a way to see how much power each patch is sucking? It'd be superb to have a way of seeing which parts of the composition are causing the slowdowns, and where to optimise!

yanomano's picture
yes profiling wiki !

It would be very instructive ! Perhaps to add in the wiki list ?

cwright's picture
hmm....

Developer-wise, there are simple ways to find out how much your patch is taking relative to all the others, and which functions/which lines of code are eating up that time (and sometimes basic hints as to why). This is all possible using "Shark".

Since QC's a stripped binary (all the information like line numbers, functions, etc is removed), I don't think shark indicates which part of it take a long time (which is what you're asking about). It would be nice though -- definitely feature-request-worthy.

(There's nothing as annoying as seeing "0x1111 QC [This program has no symbol information]" taking 86% of your cpu time, and having no idea which patch/function it is...)

psonice's picture
extended debug mode?

How about something like an extended debug mode, with some per-patch stats.

I think something as simple as time taken in ms shown in the title of each patch in the editor would give us what we want? Perhaps with a split between CPU and GPU time?

cwright's picture
profile mode

that's more of a Profile Mode than a Debug mode (debug is for fixing bugs, profiling is for fixing performance). CPU/GPU split would be nice too -- some patches are surprisingly CPU-bound, while others are very gpu-heavy. it's hard to know which is which until you play with them some.

CPU-wise, it's easy to measure load in software (just measure the time from start to finish). I'm not sure there are equivalent metrics for GPUs (other than the same measure time in GL code or whatever)...

[infact --- we could make plugins that override the built in patches to measure this information..... that's a huge but simple project that could be really helpful. any sponsors? ;) ]

psonice's picture
Yes, profile mode

Profile mode is exactly what I was thinking of. I rarely use debug or profile actually, so I think they'd blended into the same thing in my memory :)

This would definitely be handy as a plug-in. A few notes:

  • I think it'd only be really necessary for certain patches (although it would be best if it worked for them all). Particularly javascript, iterators, and CI filter/GLSL type patches that tend to eat up speed with a fairly small mistake sometimes.

  • It'd definitely be useful for macro patches. Especially if you lay out compositions like I do, with a logical flow (usually input/control, processing, and rendering, with other macros for audio control, timers, etc.). It'd be easy then to see which part of your work would benefit from some optimisation.

  • An 'advanced' fps patch would be handy, that outputs execution time and rendering time from the profile graph (which I assume are equivalent to CPU and GPU time per frame?) With that, it'd be easy to build a simple visual indicator of how much CPU and GPU time you're using as a % of frame time, so you know how much grunt you have left to expend before the frame rate drops. I'm guessing this would be pretty easy to add in if you did the rest...

No sponsorship though I'm afraid, i'm doing all my work with this for free too at the moment. Maybe if i win a demo competition one day :)