|
Optimizing Load TimeI ran into an interesting situation recently involving the arrangement of patches affecting the load time of a composition. I am writing a comp that lets a 4x4 array of buttons control a 4x4 array of sprites. The core of the patch adds different boolean values together and is then combined into a structure heading to the sprites. It works no problem, except when I started over and loaded the comp it took on average 45 seconds to load. What? It ran just fine and was smooth prior. Although the layout is a massive amount of math patches I felt that there should not be a reason it takes so long to load. Of course once it does load it runs just fine. Also, entire program is only 2.9mb Is it because Quartz compiles the composition before each load? I then decided to play around and found that the more nested the functions were the faster it loaded. I started by taking chunks and making them macro patches - below you can find an image illustrating this. And by combine I mean the code stayed the same it was only how it was arranged that differed. Is this per usual? I had no idea that the nesting of patches had anything to do with loading a comp. In fact I thought that it would make it faster if all macros were exploded. Can anyone shed light on this or point towards a resource that covers this? Any insight appreciated.
|
Pretty hard to say without examining the comp, can you post even a sub ssection of it say the 5second version?
I've had much larger comps than that load in a few seconds and math exp patch is one of the fastest executing patches in QC. QC doesn't compile at load or any other time, it's a run-time interpreted language but it does have to restore the editor window with all the patch objects and wires. Have you tried switching to straight wires using the Kineme Core patch? (I you have it loaded you have the K Menu in menu bar. Goto K preferences and set to straight, the only way to work with large comps ;-). I think one of the new QC extension patches like Origami has straight noodles too, can't recall where I saw it.
As a crude stab in the dark, when I was making a kind of tool for saving composition inline values to paches (like a Roland synth bank with 88 memories that you could save and restore with a single button, VDMX in QC I guess :-) ), I was storing potentially hundreds of objects for each patch in an array so I packaged anything 10 or over object values into a structure and then again if those structures got to ten or over. That meant less wiring and I could use repeatable macro's to compact and expand these handling structures. Less evaluations as far as the Editor is concerned and less wires at any given view level.
I was going to post a comp for you demoing what I mean but they use Data Tool structure patches and spooky so unless I reboot in some old OS I can't even restore something to show you. Here's some screen shots with missing patches:
The 45 sec version gives you the chance to do a CPU sample of QuartzComposer and see, where it is waisting time. My guess it, that QC is redrawing the complete window for each connection at loading time and so the time increases exponential per noodle. Can you do a "Sample Process" with "Activity Monitor" app by Apple? Maybe this makes a nice bug report for Apple!
Usefuldesign, I tried switching to straight noodles (which does look much better) but this afforded no efficiency boost. I have provided the composition for example. It does not need to be hooked up to inputs or outputs to exhibit this behavior so I left them unplugged. Like I said, imagine a 4x4 array of buttons adding to a 4x4 array of sprites. When I take out the problem code and load it into a blank canvas such as uploaded, it still represents a bulk of the slowdown. When I take it out of the larger, full, +/- 3mb file, it loads right away; so I am pretty confident it is whiting the way this section loads.
I checked for comp for patches I made but did not see any, I will add them if they come up missing, just let me know.
This also runs in 32-bit mode.
Achim, I will provide the sample from the 45-sec Quartz Composer comp while it attempted to load the composition. Note, it says "not responding" if you pull up the force quit menu... but eventually loads. While non-responsive I took a snap shot. Sorry for the excessive amount of text in the sample.
What is it that I should be looking for to diagnose the problem?
Note sure why the quotes didn't work either: http://kineme.net/filter/tips?bare=1
You can see in the sample log, that QuartzComposer is doing its job: reading in the file. The system sampled QC 2457 times and shows that QC never got back to the main run loop and therefore your are getting the spinning beach ball. No worries, QC is still working! :-)
[QCView loadCompositionFromFile:stateOK:] -- loading the composition QCPatchFromCompositionWithOptions -- trying to instantiate a patch [QCPatch(Override) createConnectionFromPort:toPort:forKey:] -- build the connections to other patches [QCPatch(Private) _invalidateTimeMode] -- guessing: check what time mode we are in (relative to enclosing patch, or system time based, or what ever)
and here the trouble begins:
[QCPatch(Private) __isPatchInUse:] -- QC is checking recursively (maybe the render three up) which patches are in use. I guess this will be done for each connection over and over again, because the information isn't cached.
I can't explain why it helps to put everything into macros, however I would try to change the timing mode for patches (e.g. the timeline patch has one) and see, if it makes a difference.
Sorry, I didn't look at your composition, those are just assumptions from the sample log you provided, thought.
best,
Achim Breidenbach Boinx Software Ltd.