Re: Developing Tool for Audio program
Re: Developing Tool for Audio program
- Subject: Re: Developing Tool for Audio program
- From: Brian Willoughby <email@hidden>
- Date: Thu, 25 Dec 2003 15:55:31 -0800
[ 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. 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.
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.
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.