@@ -22,6 +22,15 @@ Puis décommenter `compare_taille` à la fin et expliquer les résultats.
Bonus : faites varier `nb_niveaux` et `gamma`, voyez quelle influence ils peuvent avoir.
`nb_niveaux`:
- Lorsqu'on augmente le nombre de niveaux :
- réduit les collisions possibles car elles sont davantages réparties
- peut augmenter la taille de la MPHF, car chaque niveau correspond à une nouvelle table de hachage
- Lorsqu'on diminue le nombre de niveaux :
- le risque de collisions augmentes
- peut réduire la taille de la MPHF
Il faut donc un nombre de niveau suffisant pour éviter les collisions mais pas trop élevé afin de limiter l'espace utilisé par la MPHF.
# Partie 2 - Analyse de performance de dictionnaires en Python
On travaillera sur `tp_2_miso_dict.py`
...
...
@@ -72,13 +81,13 @@ cf Script
10. Commentez vos résultats.
1: On observe que plus les facteurs de charges sont importants plus les temps d'insertions sont longs. En effet, on peut voir sur le graphique une courbe à la tendance croissante.
1: On observe que plus les facteurs de charge sont importants, plus les temps d'insertion sont longs. En effet, on peut voir sur le graphique une courbe qui tend à croître.
Ce phénomène peut être expliqué par les risques de collision accrus et le besoin de réallouer de la mémoire pour insérer un nouvel élément lorsque le facteur de charge est élevé.
2: On a inséré 1 000 éléments dans le dictionnaire et on observe un nombre de réallocations de mémoire différent entre les facteurs de charge.
Pour le facteur de charge le plus faible, 2 réallocations ont été réalisées contre 9 pour ceux allant de 0.7 à 1.0. On atteint alors un pallier où les risques de collisions sont assez faibles pour que Python n'est plus besoin de réallouer de la mémoire afin les éviter. On en déduit donc que pour les 1000 éléments, après 9 réallocations, la mémoire ne dépasse les 2/3 de la taille du dictionnaire.
On observe également un plateau à 8 réallocations pour les facteurs 0.4, 0.5 et 0.6. On peut alors supposer que la réallocation supplémentaire pour les facteurs suivants est causé par le remplissage immédiat des 2/3 de la mémoire. En effet, Python réalise cette action lorsque le dictionnaire est remplie au 2/3 or, 2/3 = 0.66 ce qui pourrait expliquer le plateau suivant.
Pour le facteur de charge le plus faible, 2 réallocations ont été réalisées contre 9 pour ceux allant de 0.7 à 1.0. On atteint alors un pallier où les risques de collisions sont assez faibles pour que Python n'est plus besoin de réallouer de la mémoire afin les éviter. On en déduit donc que pour les 1000 éléments, après 9 réallocations, la mémoire ne dépasse pas les 2/3 de la taille du dictionnaire.
On observe également un plateau à 8 réallocations pour les facteurs 0.4, 0.5 et 0.6. On peut alors supposer que la réallocation supplémentaire pour les facteurs suivants est causée par le remplissage immédiat des 2/3 de la mémoire. En effet, Python réalise cette action lorsque le dictionnaire est rempli au 2/3 or, 2/3 = 0.66 ce qui pourrait expliquer le plateau suivant.
3: Sur le graphique représentant la taille mémoire occupée en fonction du nombre d'éléments que plus on a d'éléments dans le dictionnaire plus la taille mémoire occupée est importante. On retrouve une courbe semblable à celle correpsondante au nombre de réallocations mémoire en fonction des facteurs de charge. Ceci expliqué par le fait que selon le facteur de charge, de la mémoire est réalloué afin de permettre l'insertion d'éléments et que le facteur de charge correspond aux nombres d'éléments / taille interne de la table de hachage.
3: Sur le graphique représentant la taille de la mémoire occupée en fonction du nombre d'éléments, que plus on a d'éléments dans le dictionnaire plus la taille de la mémoire occupée est importante. On retrouve une courbe semblable à celle correspondante au nombre de réallocations mémoire en fonction des facteurs de charge. Ceci est expliqué par le fait que selon le facteur de charge, de la mémoire est réalloué afin de permettre l'insertion d'éléments et que le facteur de charge correspond aux nombres d'éléments / taille interne de la table de hachage.
4: On peut voir sur l'histogramme que le temps d'insertions dans un dictionnaire Python est rapide. En effet, malgré les coûts liés à la mémoire lors de l'insertion, ils ont été optimisés afin de rendre efficace leur utilisation.
\ No newline at end of file
4: On peut voir sur l'histogramme que le temps d'insertion dans un dictionnaire Python est rapide. En effet, malgré les coûts liés à la mémoire lors de l'insertion, ils ont été optimisés afin de rendre efficace leur utilisation.
