forked from menault/TD1_DEV51_Qualite_Algo
25 lines
1.5 KiB
Plaintext
25 lines
1.5 KiB
Plaintext
|
En compilant ./student_rank avec 1000 élèves et 1000 notes, on a remarqué que le temps d'exécution était environ 3s.
|
||
|
|
|
||
|
|
En utilisant gprof ./student_rank, on a pu voir que la fonction bubblesort prenait 77.50% du temps d'exécution soit 2.29s avec 1 001 000 appel de la fonction contre 1 000 000 pour la fonction find_rank_student qui prend 20.98% du temps total.
|
||
|
|
|
||
|
|
gprof affiche le Flat Profile qui permet de mesurer le temps et le nombre d'exécution par fonction.
|
||
|
|
Il affiche aussi le Call Graph qui permet de visualiser les appels de fonctions (qui appel qui) et son nombre d'exécution par fonctions.
|
||
|
|
|
||
|
|
Ici, bubblesort est trop lente et a nombre important d'appel dans la fonction find_rank_student.
|
||
|
|
|
||
|
|
L'idée est donc d'optimiser le nombre d'appel dans la fonction find_rank_student.
|
||
|
|
|
||
|
|
En observant le code, l'appel de bubblesort dans la fonction find_rank_student était inutile. En le retirant, le programme ne prend plus que 0.079s. Le problème maintenant, c'est que le codeest bug.
|
||
|
|
|
||
|
|
Le problème était dans la fonction bubblesort qui déterminait une liste trié quand le nombre de swap (de changement dans le tri à bulle) n'était pas égal à 1. En modifiant par > 0, cela fonctionne.
|
||
|
|
|
||
|
|
En utilisant gprof, on se rend compte que le programme prend autant de temps mais utilise moins d'appel. (1000 contre 1 000 000)
|
||
|
|
|
||
|
|
Pour optimiser le code, on peut utiliser un autre algo de tri comme heapsort.
|
||
|
|
|
||
|
|
Dans le fichier heapsort.c, des fonctions d'un algo de tri plus rapide sont disponibles : quicksort.
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|