On 30/05/2011, at 10:26 PM, Oleg Krupnov wrote:
> I knew this question was coming! :) Well, maybe you are right. The
> problem is that the function foo() involves much stuff, including disk
> I/O operations, so measuring its performance is quite tricky, you get
> different result on each test, depending on the available memory, disk
> busyness etc. It's hard to make a clean experiment. Generally, the
> foo() needs to be as fast as possible, because it is already long
> lasting. I have been optimizing foo() before, and now I need to make
> only a small change (choose x or y), and I am lazy to bother with
> profiling again, I just wanted to make the most optimal possible thing
> up front. Maybe it's just nit-picking... But I became curious if the
> above idea would be feasible at all!
This suggests that the optimisation you're contemplating is not going to be worthwhile. The tiny gains you might see due to eliminating one test-and-branch per loop are going to be swamped massively by these other things going on. It's not a case of not making a clean experiment, it's not going to be measurable*. In any case, the optimizer will probably move all of the loop-invariant state outside the loop for you, and it's likely to do a better job than your home-grown attempt.
That said, I'm not sure how portable it is, but you could use offsetof() instead of pointer arithmetic, which is always a risky business.
*Let's put some hypothetical numbers on this. Suppose your loop on its own, doing nothing else, takes 1mS. Your optimisation goes in and hey-presto, it takes 0.5mS. That looks great, a 100% improvement. Now add in all the "real world" code that has to be executed. It now takes 5 seconds. The 0.5mS you got is now a 0.01% improvement. QED.
--Graham
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden
