This is an archived project. Repository and other project resources are read-only.
Admin message
GitLab now enforces expiry dates on tokens that originally had no set expiration date. Those tokens were given an expiration date of one year later. Please review your personal access tokens, project access tokens, and group access tokens to ensure you are aware of upcoming expirations. Administrators of GitLab can find more information on how to identify and mitigate interruption in our documentation.
@@ -60,54 +60,63 @@ Le Main va ensuite créer une structure en fonction des paramètres qu'on lui a
Description de la plateforme de test
### Description de la démarche systématique
Description de la démarche systématique et de l'espace d'exploration pour chaque paramètres.
- taille : taille de la structure, fixe à 100 000 éléments
- nbOperation : nombre d'itérations pour chaque opération -> effectuer une observation à plus ou moins grande échelle, va de 50 à 250 avec un pas de 50
- operation : String de l'opération courant (Add, Remove, etc), il y en a 8 afin de pouvoir faire une observation d'ensemble sur toutes les opérations d'un coup
- type : String de la structure courante. Il y a 4 structures (Tableau, Arraylist, Linkedlist et ChainedList) afin de pouvoir faire une observation sur chacune d'entres elles
- Les observation sont : le temps CPU sur x nombre d'opération et la consommation mémoire.
```
Suite des commandes, ou script, à exécuter pour produire les données.
library(ggplot2)
perf <- read.csv2("perf.csv", sep="\t", dec=".")
GraphCPU <- ggplot(perf,aes(y = CPU, x = nbOperation, colour = Structure, shape =Structure)) + geom_point() + geom_smooth() + ggtitle("Evaluation du temps d'éxecution du CPU") + labs(y="Temps en secondes", x="Nombre d'opérations") + facet_grid(.~Operation)
GraphMemoire <- ggplot(perf,aes(y = Mem, x = nbOperation, colour = Structure, shape =Structure)) + geom_point() + geom_smooth() + ggtitle("Evaluation de la consommation mémoire") + labs(y="Temps en secondes", x="Nombre d'opérations") + facet_grid(.~Operation)
GraphCPU + coord_cartesian(ylim = c(0, 1))
```
## Résultats préalables
### Temps d'exécution
#### Dézoomé
#### Zoomé
### Consommation mémoire
### Analyse des résultats préalables
La mémoire se comporte exactement pareil sur les 4 versions.
Les temps d'exécutions dépendent essentiellement de l'affichage des valeurs du tableau.
La version 2 de recherche semble un peu plus rapide.
On constate que la mémoire agit différemment uniquement en fontion des structures et non pas des opérations sur celles-ci.
De plus, la LinkedList prend le plus de mémoire. ArrayList est la structure qui prend le moins de consommation mémoire, ce qui est logique car elle est implémentée de base par java et rapide dans le temps CPU.
Le temps CPU varie grandement entre les structures. Bien sur, nous constatons des tendances comme par exemple ArrayList et Tableau qui sont souvent joints et LinkedList et Maillon qui sont aussi joints. C'est donc cohérent par rapport au mécanisme de la structure car on voit bien que sur les méthodes comme Add (tête, queue, random) où l'on constate que le temps CPU est le même partout, ou presque pour LinkedList et ChainedList qui prennent plus ou moins de temps sur la méthode Get, ce qui est logique car ce sont des listes chainées (le déplacement prend du temps).
Cependant, sur les méthodes Remove (tête, middle) on constate un temps CPU énorme sur tableau, ce qui est logique. Lorsqu'une valeur de tableau est retirée, il faut que tous ses éléments soient décalés vers la gauche, mais quand nous avons 1 millions d'élements ou même 100 000, cela prend du temps. Les résultats sont donc cohérents car RemoveMiddle prend deux à trois fois moins de temps que RemoveTete pour tableau. Mais à part LinkedList et Tableau, les tendances sont similaires pour les autres structures sur les autres méthodes.
### Discussion des résultats préalables
Explications précises et succinctes sur ce que les limites des résultats
préalables et ce qu'ils ne permettent pas de vérifier.
Nos observation couvrent la totalité du problème, qui est ici d'analyser comment se comportent les différentes structures sur diverses opérations.
## Etude approfondie
### Hypothèse
Expression précise et succincte d'une hypothèse.
Nous avons décider de comparer le temps d'exécution et la consommation de la mémoire lorsqu'on ajoute ou qu'on enlève systématiquement un objet au début et à la fin de chacune de nos structures.
### Protocole expérimental de vérification de l'hypothèse
Nous avons également décider de comparer le temps d'éxecution et la consommation de la mémoire lorsqu'on souhaite trouver un index de manière standard (en avançant de 1 dans les structures tant qu'on n'a pas le bon index) et de manière dichotomique (diviser le nombre de valeur par deux puis comparer si la valeur est plus ou moins grande pour retirer ou ajouter la moitié des valeurs).
Ainsi, le code nous renverra l’indice qui correspond à l’endroit où la valeur voulue se trouve dans le tableau et nous aurons un résultat correspondant à l'indice de la valeur trouvée dans chaque tableau
### Protocole expérimental de vérification de l'hypothèse
- Temps d'exécution des deux programmes (et leur différence)
- Types de recherche de chaque programme (une standard et une recherche dichotomique)
- Comment le “Random” influe sur la performance des structures
- Comment améliorer la performance des deux structures
- Déterminer la classe de compléxité des structures
```
Suite des commandes, ou script, à exécuter pour produire les données.
