On Nov 16, 2011, at 10:31 AM, Don Quixote de la Mancha wrote: > I've been trying to beat these arguments into the heads of my fellow > coders since most of you lot were in diapers. Just about always the > responses are that "Premature Optimization is the Root of All Evil," > as well as that programmer time is too valuable to optimize. > > But at the same time, the vast majority of the software I use on a > daily basis is huge, bloated and slow. It has been my experience for > many years that it is simply not possible for me to purchase a > computer with a fast enough CPU, memory, network or disk drive, or > with enough memory or disk that the computer remains useful for any > length of time.
Can you confirm that the reason the particular software you use is huge, bloated, and slow is specifically because of objc_msgSend() and not shortcomings in the application's design or the addition of new, resource-intensive features to take advantage of the more powerful hardware? The "premature optimization" response is a colloquial expression of the philosophy that effort should be spent where performance metrics dictate it should. > How much do you all know about how hardware engineers try to make our > software run faster? Probably more than you realize, going by your well-meaning lecturing, interesting and informative as it is. :) These are topics that have been mulled ad nauseam. The precarious balance between efficiency and productivity is as old as software development itself. The choice of Objective-C is an acceptable tradeoff of performance for productivity and flexibility. If there is no direct evidence of user experience being negatively impacted, programmer productivity wins, because shipping software on time is as important a concern as anything else in commercial development. You're fretting over optimal memory access patterns for A8 cache lines and executable size when there is a vast spectrum of apps with varying resource requirements, for many of which such low-level information is ultimately meaningless. This goes back to the anti-premature optimization philosophy. You make specific determinations for each project and respond accordingly, because it's not going to matter if some fart app or note-taking app doesn't cache a property value. They may even use KVO extensively, bringing further overhead. If it's not sufficiently measurable in real-world usage of the app, it doesn't actually matter. Preston_______________________________________________ Cocoa-dev mailing list ([email protected]) 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 [email protected]
