Primeiro, micro-otimizações como essa raramente fazem sentido. Você deve se concentrar na capacidade de leitura e se preocupar com esses tipos de otimização apenas quando tiver identificado o código que realmente precisa otimizar criando o perfil.
Agora, se você ainda está interessado em performance, olhar para o IL não faz muito sentido, porque não é o IL que é executado.
Em vez disso, o que você deve fazer é medir .
Outra opção seria o código de máquina gerado (geralmente x86). Mas o problema é que as CPUs são muito complicadas e pode ser muito difícil descobrir qual versão do código será mais rápida.
Nota: olhar o código da máquina não é tão simples quanto abrir a janela Desmontagem. Você precisa rodar no modo Release e certificar-se de que o CLR realmente otimize o código (seja desmarcando "Supressar otimização JIT no carregamento do módulo" ou iniciando sem o depurador anexado: Ctrl + F5 , e anexando-o posteriormente, por exemplo, usando Debugger.Break()
e selecionando para depurar o código).
Se você fizer isso, provavelmente notará que ambas as versões do método serão inlined, o que torna difícil ver quais instruções pertencem ao seu método (mas ambas as versões geram o mesmo código de máquina para mim).
Se você quiser comparar as duas versões do método isoladamente, use [MethodImpl(MethodImplOptions.NoInlining)]
. Com isso, o código que estou recebendo para as duas versões do método é o mesmo:
push ebp
mov ebp,esp
mov eax,edx
imul eax,edx
pop ebp
ret