Utilisateur gil a suggéré un code dangereux qui a donné naissance à cette solution :
// Copyright (c) 2008-2013 Hafthor Stefansson
// Distributed under the MIT/X11 software license
// Ref: http://www.opensource.org/licenses/mit-license.php.
static unsafe bool UnsafeCompare(byte[] a1, byte[] a2) {
if(a1==a2) return true;
if(a1==null || a2==null || a1.Length!=a2.Length)
return false;
fixed (byte* p1=a1, p2=a2) {
byte* x1=p1, x2=p2;
int l = a1.Length;
for (int i=0; i < l/8; i++, x1+=8, x2+=8)
if (*((long*)x1) != *((long*)x2)) return false;
if ((l & 4)!=0) { if (*((int*)x1)!=*((int*)x2)) return false; x1+=4; x2+=4; }
if ((l & 2)!=0) { if (*((short*)x1)!=*((short*)x2)) return false; x1+=2; x2+=2; }
if ((l & 1)!=0) if (*((byte*)x1) != *((byte*)x2)) return false;
return true;
}
}
qui effectue une comparaison basée sur 64 bits pour la plus grande partie possible du tableau. Cela compte en quelque sorte sur le fait que les tableaux sont alignés sur qword. Cela fonctionnera s'ils ne sont pas alignés sur qword, mais pas aussi rapidement que s'ils l'étaient.
Il exécute environ sept minuteries plus rapidement que le simple for
boucle. L'utilisation de la bibliothèque J# a donné des résultats équivalents à ceux de l'original. for
boucle. L'utilisation de .SequenceEqual est environ sept fois plus lente ; je pense que c'est simplement parce qu'elle utilise IEnumerator.MoveNext. J'imagine que les solutions basées sur LINQ sont au moins aussi lentes, voire pires.
1 votes
"Cela compte un peu sur le fait que les tableaux commencent alignés sur qword." C'est un grand si. Vous devriez corriger le code pour refléter cela.
4 votes
Return a1.Length == a2.Length && !a1.Where((t, i) => t != a2[i]).Any() ;