which one is faster/better > or >=

[Mahdi]

Hi

This seems like a crazy question but I wanted to find out if anyone
knows which one of those two conditions are better (faster, smaller
memory footprint, can be optimized by the compiler, etc..)

1- if(i > 0) {// do stuff}
2- if(i >=1) {// do stuff}

Thanks.

 

[Alun Harford]

Hi

This seems like a crazy question but I wanted to find out if anyone
knows which one of those two conditions are better (faster, smaller
memory footprint, can be optimized by the compiler, etc..)

1- if(i > 0) {// do stuff}
2- if(i >=1) {// do stuff}

They both get jitted to the same x86 code on my machine.

public static void Main(string[] args)
{
for (int i = 0; i < 10; i++)
{
if (i > 0) i++;
if (i >= 1) i++;
}
}

The code in the middle becomes:

if (i > 0) i++;
0000001a test esi,esi
0000001c jle 0000001F
0000001e inc esi
if (i >= 1) i++;
0000001f test esi,esi
00000021 jle 00000024
00000023 inc esi

Alun Harford

 

[Lasse Vågsæther Karlsen]

Hi

This seems like a crazy question but I wanted to find out if anyone
knows which one of those two conditions are better (faster, smaller
memory footprint, can be optimized by the compiler, etc..)

1- if(i > 0) {// do stuff}
2- if(i >=1) {// do stuff}

Thanks.

I'm pretty sure that someone can tell you the exact answer to your
question. However, what you're looking at here will have extremely
marginal effects, if any. Any big gains you would get from optimizations
would be from overall optimizations, like replacing the algorithm
completely, removing that line of code.

 

[Lasse Vågsæther Karlsen]

Hi

This seems like a crazy question but I wanted to find out if anyone
knows which one of those two conditions are better (faster, smaller
memory footprint, can be optimized by the compiler, etc..)

1- if(i > 0) {// do stuff}
2- if(i >=1) {// do stuff}

Thanks.

And (this is my 2nd post), I'm pretty sure that if you try it, you can
probably measure the effect, if any, yourself by just executing a few
million of these statements and timing them.

 

[Ian Semmel]

If you are writing a program that uses disk io, the screen or any sort
of communications, it would be impossible to measure and would have zero
effect. Who knows what the compiler is going to do when it optimizes
code ?

Program efficiency usually comes from a good top-level design. The need
for anal-level checking like this disappeared with the pdp-8.

 

[Marra]

They execute in the same time.

 

[Rudy Velthuis]

Hi

This seems like a crazy question but I wanted to find out if anyone
knows which one of those two conditions are better (faster, smaller
memory footprint, can be optimized by the compiler, etc..)

1- if(i > 0) {// do stuff}
2- if(i >=1) {// do stuff}

There should absolutely be no difference.

 

[Mahdi]

Program efficiency usually comes from a good top-level design. The need
for anal-level checking like this disappeared with the pdp-8.

Actually I happen to have used the ">= 1" and than one of my coworkers
said use "> 0" instead. So I wanted to reply maybe it's faster but I
wasn't sure... *grin*

Thanks for the replies.

 

[Michael C]

Actually I happen to have used the ">= 1" and than one of my coworkers
said use "> 0" instead. So I wanted to reply maybe it's faster but I
wasn't sure... *grin*

Thanks for the replies.

Although it looks like your co-working is not correct in this particular
case, in general what he says is valid. It's usually better to compare
against 0 than some other number. This is because there is quite often a
build in op-code that compares with zero. Even though in this case it
doesn't look like dot net does that optimisation I still think it's better
to compare against zero as it might include an optimisation in the future.
The difference will be very minor but in some rare cases it might be valid.

Michael

 

[Jon Skeet [C# MVP]]

Although it looks like your co-working is not correct in this particular
case, in general what he says is valid. It's usually better to compare
against 0 than some other number. This is because there is quite often a
build in op-code that compares with zero. Even though in this case it
doesn't look like dot net does that optimisation I still think it's better
to compare against zero as it might include an optimisation in the future.
The difference will be very minor but in some rare cases it might be valid.

I would say it's better to write whichever code expresses the intention
more clearly.

Suppose we were testing whether or not a child should be allowed to
play with a toy, and the label says: "For 1 year and upwards." The
simplest way of expressing that is:

if (child.Age >= 1)
{
}

On the other hand, if we were examining a list and only wanted to do
something if it's not empty, I'd say:

if (list.Count > 0)

They both express the same thing (assuming both expressions use ints)
but give a different impression when reading.

I'd value that over any possible optimisation

 

[Michael C]

They both express the same thing (assuming both expressions use ints)
but give a different impression when reading.

I'd value that over any possible optimisation

Of course. But in some cases you need all the speed you can get and have to
sacrifice some readability. I know the situations would be rare but they
still exist where every bit of speed is required.

Michael

 

[Larry Smith]

Of course. But in some cases you need all the speed you can get and have

to sacrifice some readability. I know the situations would be rare but
they still exist where every bit of speed is required.

"Rare" is an understatement. I'd challenge anyone to show me a real-world
Windows program where slicing and dicing a few nanoseconds is going to make
any appreciable difference even if you could pull it off. The ambient
temperature of the room probably has a greater impact on performance.

 

[Arne Vajhøj]

This seems like a crazy question but I wanted to find out if anyone
knows which one of those two conditions are better (faster, smaller
memory footprint, can be optimized by the compiler, etc..)

1- if(i > 0) {// do stuff}
2- if(i >=1) {// do stuff}

I agree with the others that have suggested to spend your time
on something more productive.

I will just add one additional note: you can measure current
..NET version on current CPU's. But there are not guarantee that
the results will stay valid forever.

Arne

 

[Michael C]

"Rare" is an understatement. I'd challenge anyone to show me a real-world
Windows program where slicing and dicing a few nanoseconds is going to
make any appreciable difference even if you could pull it off. The ambient
temperature of the room probably has a greater impact on performance.

It's not that rare. Any algorithm that loads all its data at the start, does
some lengthy processing, and saves the results at the end will benefit. I
have four such algorithms in my app.

Michael

 

[Lasse Vågsæther Karlsen]

Although it looks like your co-working is not correct in this particular
case, in general what he says is valid. It's usually better to compare
against 0 than some other number. This is because there is quite often a
build in op-code that compares with zero. Even though in this case it
doesn't look like dot net does that optimisation I still think it's better
to compare against zero as it might include an optimisation in the future.
The difference will be very minor but in some rare cases it might be valid.

Michael

If, at that point, the compiler is smart enough to optimize > 0 faster
than >= 1 then surely it would detect that >= 1 is the same as > 0.

Write the code that makes sense. Optimizations are best done on higher
levels, not on this microlevel.

 

[Larry Smith]

"Rare" is an understatement. I'd challenge anyone to show me a real-world

It's not that rare. Any algorithm that loads all its data at the start,
does some lengthy processing, and saves the results at the end will
benefit. I have four such algorithms in my app.

This type of hairsplitting won't benefit you in any way you'll ever notice.
From a performance perspective, it's a complete waste of time even thinking
about it.

 

[Michael C]

This type of hairsplitting won't benefit you in any way you'll ever
notice. From a performance perspective, it's a complete waste of time even
thinking about it.

Generally I agree but there are some circumstances where it will make a
difference. Counting down to zero would be fairly small I agree but other
similar optimisations can have a big difference.

 

[NvrBst]

Generally I agree but there are some circumstances where it will make a
difference. Counting down to zero would be fairly small I agree but other
similar optimisations can have a big difference.



- Hide quoted text -

- Show quoted text -

I've never done any testing but I've seen (old code mostly) check
stuff like "if(test1 > x && test1 < x) {...}" instead of just
"if(test1 == x) {...}". I've also seen a person "optimize" their
screen pixel color search algorithm (AutoIt language) by breaking the
color their looking for into 3 parts and then doing a huge if statment
like below

if(red < chk && red > chk && blue > chk && blue < chk && green < chk
&& green > chk) {...} instead of just if(color == chk) {...}.

It made sence to me when reading it at the time i thought (the check
is running for millions of pixels and fails 99% of the time, so if
failing then fast type of thing), but I never really knew for sure.

Basically I have a question very simular to the first; is doing this
type of thing (== to < && >) faster for C# (C# is what I mainly use
now)? Or just an urban myth of the past? Its always been something
in the back of my mind that I've been curious about but never got
around to actually testing myself.

NB

 

[NvrBst]

I've never done any testing but I've seen (old code mostly) check
stuff like "if(test1 > x && test1 < x) {...}" instead of just
"if(test1 == x) {...}".  I've also seen a person "optimize" their
screen pixel color search algorithm (AutoIt language) by breaking the
color their looking for into 3 parts and then doing a huge if statment
like below

if(red < chk && red > chk && blue > chk && blue < chk && green < chk
&& green > chk) {...}   instead of just if(color == chk) {...}.

It made sence to me when reading it at the time i thought (the check
is running for millions of pixels and fails 99% of the time, so if
failing then fast type of thing), but I never really knew for sure.

Basically I have a question very simular to the first; is doing this
type of thing (== to < && >) faster for C# (C# is what I mainly use
now)?  Or just an urban myth of the past?  Its always been something
in the back of my mind that I've been curious about but never got
around to actually testing myself.

NB- Hide quoted text -

- Show quoted text -

opsy typo "so if failing then FAIL-fast type of thing".

 

[Michael C]

Basically I have a question very simular to the first; is doing this
type of thing (== to < && >) faster for C# (C# is what I mainly use
now)? Or just an urban myth of the past? Its always been something
in the back of my mind that I've been curious about but never got
around to actually testing myself.

My guess is it would be slower by a small amount but you never know. Maybe
on some processor a < is faster than =. The only way to know is try it.

Michael