On May 28, 2013, at 9:14 PM, Oleg Krupnov <oleg.krup...@gmail.com> wrote:
> The profiler is not a panacea; when you have hundreds of small, > not-so-efficient pieces of code like this, all you see in profiler is a long > list of small consumers, totaling in heavy use of objc runtime calls. Oh, also: What you’ve said above is a good reason for factoring out common code instead of repeating it in multiple places (aka “Don’t Repeat Yourself” or DRY). If you write this string lookup code once as a function/method you can use in many places, then it will show up as a hot-spot in the profiler if it’s slow, and then optimizing it in one place will speed up your app. If you copy/paste the code instead, the time will be split up among multiple copies of it so it’s less likely to show up, and even if it does show up you’d have to implement the optimization in many places. (Unfortunately if you use inline functions you can have cases where you did only write the code once but the compiler copied it into lots of places, making it not show up as a hot spot. That’s a reason to be really careful about inlining; it can backfire on you. Mostly that's only a problem in C++ though, where inlining and templates are used a lot and it’s easy to write code that looks short and simple but explodes into a lot of instructions. I’ve had the “fun” of trying to optimize code like that before.) —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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
