performance - Comparison

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi!

I have a simple doubt abt the performance when comparing variables with
constats values..

Can any one tell me whether to use
1.
int a;
if(a==10)
{
MessageBox.Show("done");
}

Or

2.
int a;
if(10==a)
{
MessageBox.Show("done");
}

for comparing a variable.. which one will be wise to use if we are
considering performance to be critical and why??

thanks,
Baren
 
Baren said:
Hi!

I have a simple doubt abt the performance when comparing variables with
constats values..

Can any one tell me whether to use
1.
int a;
if(a==10)
{
MessageBox.Show("done");
}

Or

2.
int a;
if(10==a)
{
MessageBox.Show("done");
}

for comparing a variable.. which one will be wise to use if we are
considering performance to be critical and why??

thanks,
Baren
Click to expand...
It doesn't matter, both should produce basically the same IL, but with 2
lines reversed... If you have performance issues, I doubt they're caused
by an integer comparison - that should be quite fast. Perhaps you could
profile your code to see.
 
Hello Baren,
Hi!

I have a simple doubt abt the performance when comparing variables
with constats values..
Click to expand...
<snip>

Int32 a = 5;
0000003d mov dword ptr [ebp-44h],5
Boolean b1 = a == 10;
00000044 cmp dword ptr [ebp-44h],0Ah * comparison #1
00000048 sete al
0000004b movzx eax,al
0000004e mov dword ptr [ebp-48h],eax
Boolean b2 = 10 == a;
00000051 cmp dword ptr [ebp-44h],0Ah * comparison #2
00000055 sete al
00000058 movzx eax,al
0000005b mov dword ptr [ebp-4Ch],eax

Equal code, same performance. Could be different if the object in a overloads
the equality operator, or is a class (in which the null-issue might crop
up), but in your example it will have the same runtime performance.
 
Hello John,
It doesn't matter, both should produce basically the same IL, but with
2 lines reversed... If you have performance issues, I doubt they're
Click to expand...

You're basically right, the IL is different, but the native machine code
(at least on my intel laptop) is the same.
caused by an integer comparison - that should be quite fast. Perhaps
you could profile your code to see.
Click to expand...

Yes, always a good idea. Effective optimizations are almost always performed
after doing the measure-first-cut-later approach instead of the hunt'n'peck
approach.
 
Lasse said:
Hello John,



You're basically right, the IL is different, but the native machine code
(at least on my intel laptop) is the same.


Yes, always a good idea. Effective optimizations are almost always
performed after doing the measure-first-cut-later approach instead of
the hunt'n'peck approach.
Click to expand...
That's pretty much what I had expected. The JIT compiler optimizes
pretty well. Comparing A to B or B to A is really the same operation so
it only makes sense it rearranges in the optimal order (in terms of
execution speed).

And either ways it should be lightning quick. Comparing integers is a
single opcode (cmp; although there is more "associated" to dealing with
the result after the cmp), but with today's processors this should not
be a speed issue of any kind (around a couple microsecond perhaps?) -
even in a pretty intensive loop (unlike complex string operations or
such, and even then).
 
Comparisons are performed mathematically. In each case, the variable "a" is
resolved to a number, and one number is subtracted from the other. If the
result is 0, the return value is true. Let's say that "a" is equal to 11.
Which is faster? Subtracting 11 from 10, or subtracting 10 from 11?
Obviously, both operations are the same.

In other words, in both cases, exactly the same work is performed in exactly
the same way. When this is the case, there is no difference in performance.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
You can lead a fish to a bicycle,
but it takes a very long time,
and the bicycle has to *want* to change.
 
Back
Top