On Nov 16, 2011, at 9:31 AM, Don Quixote de la Mancha wrote: > According to Instruments, my iOS App now spends about half its time in > a C (not Objective-C) void function that updates the state of a > Cellular Automaton grid, and the other half in a low-level iOS Core > Graphics routine that fills rectangles with constant colors. > > Despite that I implemented my own most time-critical routine in C, > objc_msgSend takes up two percent of my run time.
Do you know how much of your run time is in the overhead of preparing and making C function calls? > I expect it would be a lot more if I didn't implement that grid update > routine in C. Probably true. The tight integration with C and C++ code is one of Objective-C's great strengths over other high-level object-oriented languages. > 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. I > expect each such CFString is either a selector, or one component of a > selector that takes multiple paramaters. The selector table has no CFStrings in it. The selector table is typically smaller than 300,000 entries. The selector table is unused in nearly all Objective-C method calls. You should use Instruments to find out why your app is allocating 300,000 CFStrings at launch. > A few nights ago I decided to put quite a lot of time and effort into > refactoring the code so as to reduce my executable size. I know a lot > of algorithmic improvements that will speed it up dramatically, but > I'm putting those off until my refactoring is complete. > > At the start of refactoring, Warp Life's executable was about 395 kb. > I've done most of the refactoring that I can, with the result being > that its executable is about 360 kb. That's about a nine percent > reduction in code size that resulted from twelve hours of work or so. > I assert that is a good use of my time. Were you able to measure a performance improvement? The dyld shared cache on my Mac is 300 MEGABYTES. And that's just the system's shared libraries for a single CPU architecture, never mind the kernel or drivers or applications. Is it bloated and inefficient? No, it's big because it does lots of stuff. Do you propose that we hand-tune the assembly code and memory cache behavior of all of it? We do in fact perform that level of performance optimization on the most time-sensitive code. For example, objc_msgSend on x86_64 is carefully arranged to fit as well as possible into current CPUs' decode and execution units. Much of the rest of the system also gets performance attention, just not at that level of detail. But for almost everything, "make the computer do something that it already does but faster" needs to be balanced against "make the computer do something new". -- Greg Parker gpar...@apple.com Runtime Wrangler _______________________________________________ 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
