On Wed, Nov 16, 2011 at 10:29 AM, Preston Sumner <preston.sum...@gmail.com> wrote: > 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.
Did you ever use any of the early releases of Mac OS X? It was so slow as to be largely unusable until 10.3 (Panther). Mac OS X had been shipping to end-users for quite a long time before most end-users gave up Classic completely. Professional audio in particular just didn't work in OS X for quite a long time, so serious audio people had to stick with Classic. In particular, Xcode's text editor used to drive me absolutely bananas. I was told that was because it used the Cocoa text widget. By contrast, the CodeWarrior and TextWrangler text editors have always been snappy and responsive. It is only recently that the responsiveness of Xcode's text editor doesn't make me feel like I'm pounding nails with my fists. Having a harmoniously-designed architecture with easily understandable class interfaces is nice and all, but it's no substitute for performant code. There's more to that "Premature Optimization" quote, let me Google it up for y'all: "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%. A good programmer will not be lulled into complacency by such reasoning, he will be wise to look carefully at the critical code; but only after that code has been identified"[5] — Donald Knuth http://en.wikipedia.org/wiki/Program_optimization So many quote Knuth's advice as the reason one should not optimize, but his classic Art of Computer Programming texts from the 1960s examine a whole bunch of algorithms in a lot more detail than do most modern algorithms books. It is my experience that very few of the coders I have ever met pay any attention at all to hardware or system architecture when profiling or optimizing their code. For example, when Bjarne Stroustrup first designed the C++ language, it was thought that easy-to-use inline functions would greatly speed up any program. But they actually slow down your code when they interfere with cache utilization. I have just as many gripes, actualy more, with my colleagues' C+= than I do with the Objective-C that I've seen. Overuse of inlines, as well as poor implementations of them is a major gripe, but just one of many. Many real-time systems do not have memory cache at all. While cached memory makes it cheaper to make your program go faster if you access it the right way, it also makes it a lot harder to predict how long your tasks will take to complete. That's not cool if someone will get killed if your device doesn't respond according to the designer's specifications! Embedded developers deal with that problem by not using cached memory, preferring hand-rolled assembly code instead. The ARM Holdings website has oodles of technical articles about how to do that, as do Intel's and AMD's websites. -- Don Quixote de la Mancha Dulcinea Technologies Corporation Software of Elegance and Beauty http://www.dulcineatech.com quix...@dulcineatech.com _______________________________________________ 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
