Re: Developing Tool for Audio program
Re: Developing Tool for Audio program
- Subject: Re: Developing Tool for Audio program
- From: Kurt Bigler <email@hidden>
- Date: Sun, 28 Dec 2003 19:11:08 -0800
on 12/25/03 3:55 PM, Brian Willoughby <email@hidden> wrote:
>
[ I'd certainly prefer to use Obj-C for AU internals --
>
[ though I would be concerned about method-lookup overhead. As
>
[ much as I like OO languages (and Obj-C in particular), I tend
>
[ to be very conservative about audio and MIDI code and thus
>
[ tend to use plain C for that stuff.
>
>
The myth of method lookup overhead is what scares most people. Apple made it
>
clear at the 1997 WWDC that Objective-C method calls were on par with C++
>
calls.
At the same time apple has since been doing this horrendously slow
"optimizing" step in all their installers to make up for the fact that the
method lookups are slow enough that it is worth doing this optimization when
possible. And I seem to remember how much faster applications got when
Apple first introduced that install-time optimization - but that was years
ago now. And I was never clear exactly why that was, and it is not
necessarily a proof of slow method dispatch, if in fact optimize-at-install
was just seen as a better alternative to optimize-at-launch for example. I
don't know that this whole scenario is clearly explained anywhere, but it
would be good to understand it.
>
They went so far as to count instructions cycles. Plus, the proven
>
track record of the DriverKit, with its 100% ObjC implementation, shows that
>
critical code does not suffer because of the language.
But this does not explain the choice to abandon it, given its purportedly
good track record and clearly beneficial feature-set. Perhaps it was good
enough for what DriverKit did, but not good enough for more extreme
real-time needs, as in CoreAudio?
>
That said, I wouldn't use NSArray within a callback. ... and I would not base
>
interprocess communication queues or FIFOs on ObjC objects. The beauty of
>
ObjC is that plain C is always right there at your fingertips. Unlike C++,
>
the
>
ObjC compiler never inserts code without your knowledge, so you have a very
>
direct idea of what CPU resources you're taking up. I have seen plain C
>
arrays
>
with elements in the 10,000 range outperform an Array object, but this was on
>
a 33 MHz 68040! I'm not trying to single out NSArray, it's just that this
>
object does not allow the programmer to have direct control over the
>
allocation
>
of memory, and so it might not perform the best in every application. I'm
>
sure that other ObjC objects can be poor performers in certain usage cases,
>
but
>
you have the option of rewriting bits of your code in plain C if performance
>
becomes a problem.
C++ also performs just like plain C in controlled situations. For example,
it is always possible to write a C++ class that allows objects of that class
to be declared with all initialization suppressed, by providing a
constructor that does nothing. Then you are saying you know what you are
doing, but this is no different from C. Of course it may requiring knowing
a little more to know when you are using C++ in a C-like way, but that is
not much harder than knowing C++ well enough for any other purpose, which is
a real pain of a learning culVF^
-Kurt Bigler
>
Brian Willoughby
>
Sound Consulting
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.