On Nov 16, 2011, at 9:31 AM, Don Quixote de la Mancha wrote: > Despite that I implemented my own most time-critical routine in C, > objc_msgSend takes up two percent of my run time. I expect it would > be a lot more if I didn't implement that grid update routine in C.
Definitely. Time-critical inner loops should be written to be as fast as possible, and avoiding message dispatch is a good idea there. The tricky part is that, in a lot of apps, it’s not always clear what part of the code is going to be time-critical. The answer is obvious in a cellular automata simulator, but not in many other things. Thus Knuth’s dictum that “premature optimization is the root of all evil”. Typically you initially code without considering optimization (unless you’re really sure, as in your case), then profile and optimize based on that. > End-user time is even more expensive than programmer time. Yes, but that only comes into play once an end user installs your app. Programmer time is very significant _before_ that, if it either prevents the project from shipping at all, or delays shipping enough that you can’t keep up with competitors, or causes the resulting product to have insufficient testing. There are many, many examples of products that failed to get customers because of this. (A classic example is WriteNow, an early word processor for the Mac. It was coded in assembly by a team who could and did count clock cycles in their heads, so it was insanely small and fast. Unfortunately they couldn’t keep up with other word processors (especially Word), back when they were still adding genuinely useful features like paragraph styles and image wrapping, so they lost out in the market after a few good years. > That selector table is fscking HUGE! My iOS App isn't particularly > big, but Instruments tells me that just about the very first thing > that my App does is malloc() 300,000 CFStrings right at startup. Selectors are not CFStrings. They’re uniqued C strings and they’re mapped directly from the read-only TEXT section of the executable. > If the code and data are not already cached, then objc_msgSend will be > very, very slow compared to a C subroutines call. It’s slower than a C call or C++ dispatch, but it’s surprisingly fast. It has been obsessively optimized for a very long time by some very smart people. (Recent OS’s do in fact use a C++-like vtable dispatch for some common classes like NSString.) I do agree that it’s worth avoiding message-send overhead in some common situations, and I’m not fond of the “use property accessors everywhere” approach. I’ll use the ivar directly if it’s a RHS access or if it’s a scalar value. > I've been trying to beat these arguments into the heads of my fellow > coders since most of you lot were in diapers. Cards on the table: I’m 46 and have been coding since the days of the Altair and IMSAI. But I try to avoid the lengthy “back in my day we had to walk uphill both directions in the snow” rants, even if I’m entitled to them ;-) No one reads all the way to the end, anyway. —Jens _______________________________________________ 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
