Re: Do I really need to steer clear of Objective-C when providing data for RemoteIO?
Re: Do I really need to steer clear of Objective-C when providing data for RemoteIO?
- Subject: Re: Do I really need to steer clear of Objective-C when providing data for RemoteIO?
- From: Paul Davis <email@hidden>
- Date: Fri, 7 Jan 2011 13:24:46 -0500
On Fri, Jan 7, 2011 at 1:03 PM, Gregory Wieber <email@hidden> wrote:
> That kind of ignores the point of everything else I wrote, and is splitting
> hairs on wording. The word 'overhead' was meant to refer to any and all
> performance issues related to using objective-c in a render callback.
i'm sorry, but its not splitting hairs. you could use a language that
was N times slower for every instruction/operation your code
performed, and it would still be OK (if a little odd) to use it in a
render callback. suboptimal, but not inherently bad. you could also
use a assembler for everything, but from assembler still do things
that destroy the more-or-less deterministic/RT nature of the render
callback. this would be fast, but inherently bad.
it is very important to distinguish "overhead" that is deterministic
(e.g. language foo is much expensive than language bar when doing a
frob operation), and "overhead" that is causes the thread to block.
coming from the linux world, i've seen dozens of examples where
developers fail to grasp the distinction between these two things. it
happens because peo
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden