Re: Xcode 5 & Obj-C++
Re: Xcode 5 & Obj-C++
- Subject: Re: Xcode 5 & Obj-C++
- From: Jens Alfke <email@hidden>
- Date: Wed, 29 Jan 2014 16:42:18 -0800
On Jan 29, 2014, at 4:28 PM, Eric Wing <email@hidden> wrote:
> - Additionally, C++ will typically increase your compile and link times.
Oh my yes. The C++ compiler generates huge amounts of symbolic data and nearly chokes the linker. The last big C++ project I worked on (Chrome) took over a minute just to link, which meant the turnaround was at least that long if I made a one-line change. By creating a RAM disk(!) to store the build output I was able to speed that up to 30 sec, which was painful but better.
> - Binary compatibility (already mentioned) is a pain, so libraries
> need to be extremely careful.
Anyone exposing a C++ API in a dynamic library is nuts, IMHO. Apple did so with IOKit and I'm sure they've regretted it ever since.
> - Often when comparing Obj-C vs. C++, method dispatch is one of the
> main culprits for the performance difference.
That's one of them. The other major one is the way that Obj-C has to allocate all* objects on the heap, whereas in C++ you can allocate small temporary objects on the stack, or embed them in other objects.
Part of knowing how to use Obj-C effectively is knowing when _not_ to make something an object. If there will be zillions of tiny instances, or if it has to be called in ultra performance sensitive code, it's better to drop down to C or C++ for just that specific task.
—Jens
* except for a subset of NSNumbers which the runtime cleverly hides inside tagged pointers, a C++-like trick
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden