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.
I subscribed to this list just to agree with Bill, here. Every good
developer I know has found a speed-up in completely adopting Objective-
C and Cocoa, NOT a slowdown. Of COURSE you can write bad code in
Objective-C. But it encourages you not to.
In my experience, MOST programs out there suffer from performance
problems that are caused by large-scale inefficiencies, NOT small-
scale inefficiencies:
For example, a large-scale inefficiency would be a database interface
where you malloc() and copy the data six times before the user sees
it, instead of just retaining it and passing around the same pointer.
(This was really the case with the original DBKit (predecessor to EOF,
predecessor to CoreData), except I think it was more than 6, it was,
like, 15.) Method calls are nothing compared to memory allocation, yet
people spend most of their time freaking out about the overhead of a
method, and none thinking, "Damn, it's nice to have a coherent
strategy for handling memory."
Using Cocoa means those kinds of problems are avoided from the start.
On the other hand, a small-scale inefficiency would be, like, a tight
loop where you run through a buffer and increment each byte by two.
And honestly (a) compilers are good at optimizing this kind of thing,
(b) it's really not very common, and (c) processors are super-fast
anyhow. And usually the best answer is to go higher-level with these
problems, anyways (eg, use vecLib).
--
Think about the kinds of problems that are slow. What do they involve?
Usually, large data sets. I mean, if you're doing only one operation,
it's REALLY hard to make that slow, nowadays.
Apple's spent a TON of time optimizing their collection classes.
NSArray, NSSet, NSDictionary -- they are all on their, like, fifth
iteration. You're not going to do better straight out of the gate,
certainly not re-writing them in straight-C.
--
I will go this far: I would never hire anyone who complains seriously
about Objective-C being slow, because what you have there is someone
who hasn't written a complete system. She's a theoretical programmer,
not a real one. "In THEORY, straight C should be faster." Yes, if
*you* were a perfect programmer, and could rewrite very complex
systems from scratch in a low-level language without introducing any
bugs on inefficiencies... but the last 50 years of computer
programming have proven that there are maybe four or five programmers
in the world like this. (John Carmack, for instance.)
-Wil
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
