> One thing in the code that I was curious about is.. the QCPlugin
> documentation (or maybe it's the QC Custom Patch Programming Guide - I can't
> find it now) says to use port properties as little as possible in
> execute:atTime:withArguments... it says something about caching them in other
> variables if they're going to be used repeatedly. I'm not sure why this is
> - for performance or because the values could change unexpectedly. These
> patches are all pretty simple so it doesn't seem like much of a concern, but
> I wondered if even something like this is using those properties too much:
>
> http://code.google.com/p/rdqcutils/source/browse/trunk/ScaleNumber.m#169
>
> I started to make variables to store the port values before
> comparing/calculating but it looked like a lot of work and it was ugly/clunky
> - especially considering the patches seem to be working fine as-is. Does
> anyone have an opinion on this?
It's not quite a matter of opinion. It's entirely for performance reasons (not
because the values may change unexpectedly).
Every time you access a property, the compiler emits a function call. This is
typically more expensive than accessing a member of a struct (which is simply
an address offset calculation + a load). For some properties (atomic ones, in
particular), a lock might be taken as well. This is also more expensive. (in
practice locks for properties are pretty rare from what I've seen -- I could be
wrong though).
Note that when I say "expensive" above, I mean on the order of a few dozen
nanoseconds. Not a big deal in the grand scheme of things -- it won't double
your framerate or anything except in mircobenchmark type tests. However, if
you want truly performant patches, locally caching properties will yield some
benefits (normally the QC runtime itself will cost more than things like this,
but I opine that every saved cycle helps).
The linked example you provided is trivial to "localize" (not in the
translation sense) -- I typically do something like this:
-(BOOL)execute:…
{
int inputValue = self.inputValue;
/* replace all instances of "self.inputValue" with just "inputValue" */
return YES;
}
That way it's still clear what's going on.
Also in the linked example, there's "self.theNum" -- I don't know why they're
using an ivar + property instead of a local variable, since it looks like
theNum is only used inside -execute:. That seems totally unnecessary.
The -execute: method is calling 24 functions to set or get properties. Yet
there are only 6 actual properties in play (inputOldNum, inputOldMax,
inputOldMin, inputNewMax, inputNewMin, and outputNewNum). so it's doing 4x
more work/function calls than it needs to (the math for this function is
trivial, such that the cost is negligible either way).
--
Christopher Wright
[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]
