forked from menault/TD1_DEV51_Qualite_Algo
18 lines
1.7 KiB
Plaintext
18 lines
1.7 KiB
Plaintext
GPROF : FONCTIONNEMENT
|
|
|
|
Deux métriques sont utilisés lors des mesures : le temps, et le nombre d'appels.
|
|
Dans un premier tableau, dit Flat Profile, il donne la consommation du temps en pourcentage par rapport au temps d'exécution total, ainsi que le nombre d'appels sur ce même temps. Il fait cela en mesurant tous les centièmes de secondes.
|
|
|
|
D'après ce premier tableau, on constate que le tri bulle consomme nettement plus
|
|
que n'importe quelle autre fonction du programme, avec une consommation d'à peu près 80% du temps total d'exécution. La deuxième fonction consommant le plus est find_rank_student, avec une consommation de 20%.
|
|
|
|
On a aussi le callgraph, qui permet de hiérarchiser les fonctions selon qui appelle qui, en indiquant le nombre d'appels et les temps d'exécution individuels de chaque sous-fonctions.
|
|
|
|
Ici, on voit que la fonction bubblesort est appelé 1 million de fois par find_rank_student; c'est sûrement ce qui pose un problème.
|
|
|
|
Cela nous permet de voir qu'il y a un appel en trop de bubblesort dans find_rank_student. Une fois retiré, et Gprof relancé, bubblesort n'est appelé plus que mille fois. Mais, l'algorithme reste toujours trop lourd, et continue de consomer près de 80% du temps d'exécution total. En replaçant l'algorithme par un plus optimisé, comme le heapsort, les performances sont largement meilleures. Il n'y a plus qu'une dizaines d'opérations effectuées, et le temps de consommation est quasiment nulle pour toutes les fonctions.
|
|
|
|
L'ensemble de ces résultats sont valables pour 1000 étudiants et 1000 notes chacuns. Pour 10000 et 10000, même avec un tri par tas, l'exécution consomme bien plus.
|
|
|
|
|
|
On va donc devoir changer l'algorithmie. |