[ACCEPTED]-Use "greater than or equals" or just "greater than-c

No, there are no performance issues associated 21 with comparison operators. And any good 20 compiler would optimize something this trivial 19 anyway.

I'm not sure where you got the suggestion 18 to use "i > -1" rather than "i >= 0". On 17 the x86 architecture, it makes no difference 16 which you use: either case takes exactly 15 two instructions... one to compare and one 14 to jump:

 ;; if (i > -1) {
 cmp eax, -1
 jle else
then:
 ...
else:

 ;; if (i >= 0) {
 cmp eax, 0
 jl else
then:
 ...
else:

On most RISC architectures that 13 I know, "i >= 0" may actually be faster 12 since there is usually a dedicated zero 11 register, and "i > -1" may require loading 10 a constant. For example, MIPS only has 9 a < instruction (no <=). Here is 8 how the two constructs would be (naively!) expressed 7 in MIPS assembly language:

 // if (i >= 0) {   (assuming i is in register %t0)

 stl $t1, $0, $t0     // in C: t1 = (0 < t0)
 beq $t1, $0, else    // jump if t1 == 0, that is if t0 >= 0
 nop
then:
 ...
else:

// if (i > -1) {    (assuming i is in register %t0)

 addi $t2, $0, -1      // in C: t2 = -1
 stl $t1, $t2, $t0      // in C: t1 = (t2 < t0) = (-1 < t0)
 bne $t1, $0, else     // jump if t1 != 0, that is if t0 > -1
 nop
then:
 ...
else:

So in the naive, general 6 case, it will actually be one instruction 5 faster to do "i >= 0" on MIPS. Of course, RISC 4 code is so heavily optimizable that a compiler 3 would likely change either of these instruction 2 sequences almost beyond recognition :-)

So... the 1 short answer is no no no, no difference.

Quite apart from the fact that any decent 14 compiler does the right thing, and apart 13 from that fact that in modern architectures 12 there's no speed difference between > and 11 >= comparisons, the bigger picture says that 10 this is a "micro-optimisation" that doesn't 9 affect runtime performance in the vast majority 8 of cases.

In the case of comparisons it usually 7 doesn't affect readability whichever way 6 you write it, but there are occasions when 5 picking one boundary over the other is clearer: e.g.,

if (length >= str.size())

versus

if (length > str.size() - 1)

I 4 don't know about you, but I'd pick option 3 1 any day. :-) In cases that don't appreciably 2 affect performance, such as this, the more 1 readable option should win.

There is a very similar question (no criticism 10 implied - as you say, searching for symbols 9 is tricky) here: "Should one use < or <= in a for loop"

(Yes, I happen to be able 8 to find it easily as I've got a lot of upvotes 7 on my answer...)

Basically, do whatever's 6 most readable. The day someone correctly 5 guesses that making a change away from the 4 most readable form is going to solve a performance 3 problem (without the help of a profiler) is 2 the day I stop talking about performance 1 :)

No you don't need to do this any more. Yes 3 the compilers have become much smarter and 2 the two expressions have no performance 1 differences.

I remember from C days that we were encouraged 7 to use .... because of performance.

Are 6 you sure about that? I've worked with computers 5 going back to the early '70's (yes, at my 4 father's knee...), and I've never seen a 3 CPU that couldn't process >= just as fast 2 as >. (BH "Branch High" vs. BNL "Branch 1 Not Low" in IBM360 talk).

That might have been true for some shady 5 scripting languages that break down a >= into 4 2 comparisons, but whoever encouraged you 3 to use that for C... well... you should 2 probably try hard to forget everything they 1 ever told you.

This reminds me of the recommendation to 11 use ++i instead of i++ (pre-increment vs. post-increment) because 10 it was supposedly one instruction faster. (I forget 9 where I originally read about this, but 8 it was probably C/C++ Users' Journal or 7 Dr. Dobb's Journal but I can't seem to find 6 a web reference.)

I seriously doubt that 5 > or >= is faster or slower; instead write 4 your code for clarity.

As a side note, I 3 developed a preference for the pre-increment 2 (++i) operator even if the reason is now 1 potentially outdated.