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: Gregory Wieber <email@hidden>
- Date: Fri, 7 Jan 2011 10:18:20 -0800
Fair enough. To the original poster -- I think everyone would agree with me in saying, just stick to C in any area of your app that is time-critical, and you'll avoid a lot of issues.
On Fri, Jan 7, 2011 at 10:13 AM, Paul Davis
<email@hidden> wrote:
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.
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 people don't "split hairs" over the distinction often
enough, but instead just think in terms of "fast" and "slow.
--p
_______________________________________________
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