Re: ObjC in time-critical parts of the code
Re: ObjC in time-critical parts of the code
- Subject: Re: ObjC in time-critical parts of the code
- From: Justin Carlson <email@hidden>
- Date: Sun, 18 Jan 2009 20:05:11 -0600
> I've been watching this discussion w/great interest. Thanks.
>
> A lot of the discussion seems to be focused on micro-optimizations
and little focused on systemic optimizations.
>
> One point that I have yet to see mentioned is the overall
performance enhancements to be had by focusing on embracing the high
level services of the system.
>
> And by overall performance enhancement, I specifically mean that
it lets you ship a working product in less time. And by "working
product", I mean "product that performs well enough to keep customers
happy".
>
> As well, by focusing on achieving maximal integration of your code
into the subsystems of the system, you can often gain a tremendous
amount of efficiency.
>
> Simple question: Is it better to pursue a 20%, or even 50%,
improvement in drawing speed by rewriting in C++ or C than, say,
preventing the 2, 3, 4, or more extra redraws that are happening prior
to window flush? Don't laugh -- I have seen it happen. Often.
>
> As well, there are areas of optimization for which Apple has
entire teams dedicated to squeezing every last ounce of performance
out of every variant of CPU and/or GPU shipped.
>
> As an added benefit, doing so means that your code is much more
likely to just get faster across major releases of Mac OS X (and a
handful of minor releases, too).
>
> b.bum
>
Hi Bill,
Like all developers, I don't have the time (or desire) to implement
every aspect of a program. Implementation is of course inevitable, and
reinventing the wheel is frequently a poor use of time. For me, it
really comes down to what you're responsible for implementing. I try
to make my written code good before anyone else can use it. And yes,
using the system's APIs does have its benefits - a great selling point
for me when I chose to use Cocoa. If you find that the performance is
poor following implementation, then a programmer should be inclined to
understand why. If there is only enough time to implement some of
that, begin with the easiest changes
which_are_in_line_with_the_ideal_solution - Don't apply a handful of
mud to an existing program as a patch. Apple has invested much energy
into performance, which I'm thankful for. I have also seen
(unspecified) system libraries worsen considerably over time - 'faster
over the course of OS releases' is not as sunny as I once believed.
Believing system libraries will get faster is dangerous. Strangely,
another good reason to have solid code from the day it is written.
Thanks for mentioning bringing in these points.
J
_______________________________________________
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