Interpréter les résultats

», a produit une copie fraîche de la matrice. Ainsi, ils ont tous démarré au même endroit quand le tri a commencé. Cependant, la création de la copie a ajouté environ 20 millisecondes qui ne font pas partie des résultats des tests « prétriés ». Tenez-en compte en comparant les résultats.

De plus, vous utiliserez ces techniques de tri avec des données différentes des miennes, ce qui affectera aussi les résultats. Il en découle qu’aucun de ces chiffres ne devrait être pris comme une durée exacte, et vous devez négliger les petites différences entre eux. Ainsi, quand QSORT renvoie 0,0222 seconde et SORTA renvoie 0,0230 seconde, vous pouvez estimer sans risque que c’est la même vitesse.

En revanche, ces chiffres montrent les différences relatives de vitesse entre les techniques. Considérez la différence entre le tri de 10 000 enregistrements avec une file d’attente de données, qui a pris 3,5 secondes, et la même action avec QSORT en 0,5 seconde environ. On change d’ordre de grandeur !

Outre la performance abyssale des méthodes par index utilisateur et par file d’attente de données, j’ai été vraiment étonné par la différence de vitesse entre le tri sur un champ date et le tri sur un champ numérique ou un champ caractère. Comme la technique QSORT a utilisé le support date du RPG pour comparer les champs date et le support numérique du RPG pour comparer les codes postaux, il y a une nette différence (en diminution) des vitesses de tri de ces champs. Les autres méthodes ont utilisé les valeurs hexadécimales des champs pour t r i e r ces derniers e t , par conséquent, leurs vitesses de tri étaient presque les mêmes que pour tout autre champ.

Au bout du compte, QSORT a été la vraie star. Pensez à l’essayer dans votre prochain projet comportant le tri d’un sous-fichier.