Qual a diferença entre usar uma comparação com >= ou simplesmente >? – c# desempenho operadores

Imagine o seguinte cenário.

int i = 2;
if(i >= 2)
{
    //....
}

Quando poderíamos simplesmente resumir para;

int i = 2;
if(i > 1)
{
    //....
}

Minhas duvidas com essas duas expressões são as seguintes:

Quando uma linguagem de baixo nível interpreta este cenário ele faz duas comparações se é > (maior) ou = (igual) ao valor?

Se sim, a forma resumida if(i > 1) seria melhor em termo de processamento ou daria no mesmo?

Enfim, eu estou especificando o C# como linguagem, mas se tiver alguma diferença entre outras e quiserem complementar com isso, seria legal.

Comparar por maior ou igual pode ter um custo em ciclos de processador maior que apenas comparar com maior. Desde que essa operação realmente seja feita.

Entenda que é comum que em linguagem de máquina tenha uma instrução para fazer um ou outro operador. Não precisa de mais que uma delas para achar o resultado. Mas isso não quer dizer que o custo é o mesmo.

Uma coisa que muita gente não entende é que tamanho de código e custo para executar são coisas bem diferentes. Se código curto fosse mais rápido era só escrever Execute() e faria tudo o que deseja da forma mais rápida possível 🙂 Não existe mágica, mesmo em baixo nível que é tudo manipulação de bits algumas operações precisam de alguns passos para chegar no resultado, igual você faria no papel ou em sua cabeça. Esses passos são ciclos de execução (cada Hertz do processador). A coisa é um pouco mais complicada que isso por causa do pipeling do processador que pode executar várias coisas juntas (nada a ver com thread), mas não tem porque entrar nesse assunto aqui.

Também é importante entender que o compilador pode, em alguns casos otimizar o código de alto nível para mudar o operador e usar o que vai executar mais rápido. Você não precisa saber disso. Claro que nem sempre ele pode garantir que uma mudança não vá afetar a execução e só com garantias que a otimização não vai criar problema é que ele faria. Não estou dizendo que o compilador do C# faz, mas poderia fazer.

Veja os dois códigos como ficaria no CIL (ainda não é o código de máquina, que depende de onde será executado, mas já dá uma base). O JITter poderia otimizar na hora da execução:

.method public hidebysig static void  Main(string[] args) cil managed {
  // 
  .maxstack  2
  .locals init (int32 V_0,
           int32 V_1,
           bool V_2,
           bool V_3)
  IL_0000:  nop
  IL_0001:  ldc.i4.2
  IL_0002:  stloc.0
  IL_0003:  ldloc.0
  IL_0004:  ldc.i4.2
  IL_0005:  clt       //<=========== operador aqui
  IL_0007:  ldc.i4.0
  IL_0008:  ceq       //<=========== operador aqui
  IL_000a:  stloc.2
  IL_000b:  ldloc.2
  IL_000c:  brfalse.s  IL_001b

  IL_000e:  nop
  IL_000f:  ldstr      "Maior ou igual"
  IL_0014:  call       void [mscorlib]System.Console::WriteLine(string)
  IL_0019:  nop
  IL_001a:  nop
  IL_001b:  ldc.i4.2
  IL_001c:  stloc.1
  IL_001d:  ldloc.1
  IL_001e:  ldc.i4.1
  IL_001f:  cgt       //<=========== operador aqui
  IL_0021:  stloc.3
  IL_0022:  ldloc.3
  IL_0023:  brfalse.s  IL_0032

  IL_0025:  nop
  IL_0026:  ldstr      "Maior"
  IL_002b:  call       void [mscorlib]System.Console::WriteLine(string)
  IL_0030:  nop
  IL_0031:  nop
  IL_0032:  ret
}

Que foi compilado partindo de:

public static void Main (string [] args) {
    int x = 2;
    if (x >= 2) {
        WriteLine("Maior ou igual");
    }
    int y = 2;
    if (y > 1) {
        WriteLine("Maior");
    }
}

Note que o CIL preferiu ter duas instruções para fazer a operação (clt e ceq). Isso não quer dizer que o código de máquina fará o mesmo, depende de como o JITter criará o código nativo. Note também que ele preferiu inverter a comparação para dar o resultado desejado.

É provável que usar o operador simples dê uma performance melhor, mas isso não é garantido. Tem outras coisas mais importantes para otimizar que dará ganho maior. Bem mais.

Obviamente que isso vale para int, se tiver parte decimal é claro que eles não fazem a mesma coisa. Por isso eu costumo procurar usar a semântica mais adequada e só me preocupar com a performance em caso assim se eu medir que preciso ter esse mínimo ganho de alguns ciclos.

Eu estava pesquisando e vi que na maioria das arquiteturas atuais (na minha época fazia) não faz diferença usar um operador ou o outro, ele executam na mesma quantidade de ciclos. Não é fácil garantir nada porque até o processador faz otimizações.

Fiz alguns testes que não são os ideais (nem vou postar porque ele testa mais outras coisas que essa operação) e a única conclusão que tive é que realmente não é isso que faz diferença. Tem caso que chegou dar diferenças enormes para um lado ou outro, o que mostra que até o ambiente momentâneo influencia mais que a operação individual. Onde ela será usada influenciará também. Hoje a não ser em cálculos matemáticos muito pesados o que executa no processador faz bem pouca diferença, caro é acessar memória, isso é o que tem que se preocupar.

Tem uma pergunta no SO que fala disso com detalhes. Não sabe inglês? Esse assunto não deve interessar então.

Existe ainda um outro ponto de vista que o @bigown nao mencionou.

Imagine que você tem uma estrutura de dados com capacidade máxima. E quer verificar se a lista já excedeu essa capacidade:

var list = new List<int>(5);
list.Add(1);//... por ai fora
if(list.Count > list.Capacity){
    //excedeu a capacidade...
}

Até ai tudo bem usou o sinal > e tem o comportamento esperado. Agora imagine que por algum motivo quer verificar se a capacidade é maior ou igual, usando apenas o sinal de maior o código ficaria dessa forma

if(list.Count > list.Capacity - 1){
    //atingiu a capacidade...
}

É neste cenário que o sinal de >= faz falta.

O seu argumento é que o sinal >= é computacionalmente mais penoso e por isso deve de usar >.

Aqui o seu argumento cai em terra por você tem que fazer uma comparação e uma subtracção com 1. O código mais adequado neste caso seria

if(list.Count >= list.Capacity){
    //atingiu a capacidade...
}