> 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's a great news! If it is really so, I stand corrected and not
trying to optimize it any further.
In fact, in the meantime I created a quick and dirty prototype to
measure this operation isolated, and it seems that out of 3 options
(plain if, function pointer, and pointer arithmetics) the plain if is
the winner, surprisingly :)
I also agree with what you said about negligibility of this
optimization compared to the rest of code. It's just sometimes hard to
stop nit-picking where you think you can optimize something, you know
:)
One thing that bothers me though. How the compiler will understand
that the state is loop-invariant? Should I necessarily declare the
checked boolean state as a local stack variable (unlike to a class
member variable that may change as a side-effect, if foo() was a class
method)?
for example
- (void)foo
{
bool xOrY = m_isXOrY;
for (int i = 0; i < N; ++i)
{
if (xOrY)
{
int value = a[i].y;
...
}
else
{
int value = a[i].y;
...
}
}
}
Would this suffice?
Thanks!
On Mon, May 30, 2011 at 4:14 PM, Graham Cox <graham....@bigpond.com> wrote:
>
> 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 (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
