L’intérêt des index est bien d'accélérer le temps d'exécution et non le ralenti.
Sauf si la base est petite.
Par contre, tu peux essayer de minimiser l'influence des choses extérieures à ton programme et le faisant boucler un certain nombre de fois, et en divisant le résultat par le nombre d'itérations. C'est une des techniques de base de la mesure de temps d'exécution.
Je ne trouve pas que c'est une bonne façon de faire, c'est une façon très artificiel de faire une mesure, surtout pour un micro benchmark.
Je m'étais amusé à bencher une multiplication matriciel avec rdtsc. Le temps max était donné par la 1er itération, puis le nombre de cycle décroissait jusqu'à la 3 ième itération avant de se stabiliser : en gros tu remplis les caches. Pourtant, ton "vrai" temps est le premier, pas le plateau obtenu ensuite 10% plus rapide.
[^] # Re: Une solution à l'ancienne (en assembleur)
Posté par Nicolas Boulay (site web personnel) . En réponse au message Mesurer le temps d'exécution d'un fragment de code. Évalué à 3.
Sauf si la base est petite.
Par contre, tu peux essayer de minimiser l'influence des choses extérieures à ton programme et le faisant boucler un certain nombre de fois, et en divisant le résultat par le nombre d'itérations. C'est une des techniques de base de la mesure de temps d'exécution.
Je ne trouve pas que c'est une bonne façon de faire, c'est une façon très artificiel de faire une mesure, surtout pour un micro benchmark.
Je m'étais amusé à bencher une multiplication matriciel avec rdtsc. Le temps max était donné par la 1er itération, puis le nombre de cycle décroissait jusqu'à la 3 ième itération avant de se stabiliser : en gros tu remplis les caches. Pourtant, ton "vrai" temps est le premier, pas le plateau obtenu ensuite 10% plus rapide.
"La première sécurité est la liberté"