No puedo comentar aún, no hay suficientes representantes, pero Lior está mezclando Java con C# en una respuesta muy incorrecta.
byte en C# es un byte sin signo, que es todo lo contrario de todos los demás tipos de números enteros en C#, que están firmados por defecto.
La parte 0xFF es completamente inútil porque incluso si el byte se firmó, 0xFE, por ejemplo, es -2. Usar un bitwise -y con 0xFE y 0xFF, por ejemplo, no evitaría que el número negativo 0xFE sea el resultado. 0x7F lo haría.
Respecto a la respuesta principal, estoy bastante seguro de que estas micro-optimizaciones pueden ayudar, aunque sean micro-optimizaciones que probablemente no harán ninguna diferencia porque el compilador JIT podría hacer otra cosa y porque las computadoras son demasiado veloces.
chars[2 * i + 2] = ToHexDigit(bytes[i]/16);
chars[2 * i + 3] = ToHexDigit(bytes[i] % 16);
Pequeño cambio para hacer que use bitshift y bit opera en lugar del divisor y el módulo.
chars[2 * i + 2] = ToHexDigit((bytes[i] >> 4) & 0xF);
chars[2 * i + 3] = ToHexDigit(bytes[i] & 0xF);
Esta es la otra "optimización", aunque lo veo como algo más legible. Tal vez sea porque sé la mayoría de la tabla ASCII de memoria.
private static char ToHexDigit(int i)
{
return (char)(i + (i < 10 ? 48 : 55));
}
Si usted está tratando de lograr un menor hexagonal caso (sin ToLower), sólo cambio 55 con 87. Esto hace que sea muy sencillo.
Actualización: Parece que Lior o alguien le quitaron la respuesta. Ese fue un buen movimiento.
¿por qué el voto a favor? Por cierto, csharp-online.net tiene algunas cosas interesantes v. – russau
el enlace está ahora muerto. – Yablargo