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.
C’est la comparaison des performances de différentes structures de données et différentes implantations, pour différentes opérations,
en termes de consommation CPU et de consommation mémoire. Dans notre cas, l'objectif sera donc de comparer les performances de différentes opérations pour différentes
implémentations de l'interface List.
C’est la comparaison des performances de différentes structures de données et différentes implantations, pour différentes opérations, en termes de consommation CPU et de consommation mémoire. Dans notre cas, l'objectif sera donc de comparer les performances de différentes opérations pour différentes implémentations de l'interface List.
Description de tous les paramètres exploratoires du problème:
Les paramètres modifiables seront:
- Le choix de la structure
- Le choix de l'opération à éxecuter
- Le nombre de répétion de l'opération choisi
- Le choix de l'opération à exécuter
- Le nombre de répétions de l'opération choisi
- La taille de la structure
## Dispositif expérimental
Plan de travail:
Tout d'abord, l'objectif sera de faire de simples comparaisons sur les temps d'exécutions (et ressources utilisées) des
opérations entre deux implémentations de l'interface List. Nous prendrons ici les classes ArrayList et LinkedList et travaillerons en Java.
Suite à cela, nous créerons notre propre implémentation de List, nottament une classe qui reprendra le concept de tableau.
L'implémentation de l'interface List pour une classe utilisant un tableau peut, à première vue, sembler étrange,
mais cela nous permettra de tester cette classe de la même manière que toutes les autres, et ce, de manière simplifiée.
Tout d'abord, l'objectif sera de faire de simples comparaisons sur les temps d'exécutions (et ressources utilisées) des opérations entre deux implémentations de l'interface List. Nous prendrons ici les classes ArrayList et LinkedList et travaillerons en Java. Suite à cela, nous créerons notre propre implémentation de List, notamment une classe qui reprendra le concept de tableau. L'implémentation de l'interface List pour une classe utilisant un tableau peut, à première vue, sembler étrange, mais cela nous permettra de tester cette classe de la même manière que toutes les autres, et ce, de manière simplifiée.
### Organisation objet
note: gerer les tableaux sans debordements. (-> ArrayList se comporte comme un simple tableau)
Description de l'organisation des classes et interfaces, ou diagramme de classes:
...
...
@@ -48,31 +40,35 @@ L'application permet de faire des opérations sur different type de structure: L
- le nom de la structure (array, ArrayList ou OurLinkedList (une liste chainée crée par nous même))
- le nombre de répétition
- l'action a effectuer (les actions sont get, inserthead, insertqueue, insertrandom, remove)
Note: remove supprime un élément au hasard dans la structure, si le nombre d'element à supprimer est suppérieur à la taille de la liste,
on passe l'opération.
Note importante:
- remove supprime un élément au hasard dans la structure, si le nombre d'element à supprimer est suppérieur à la taille de la liste, on passe l'opération.
- get récupère un élément au hasard de la liste.
```
### Environnement de test
Description de la plateforme de test
La plateforme utilisé pour générer nos données est le bureau à distance (sous Unix)
La plateforme utilisée pour générer nos données est le bureau à distance (sous Unix)
```
Extrait pertinent de /proc/cpuinfo:
cpuinfo:
Nom de modèle : Intel(R) Xeon(R) CPU E5-2630 v4 @ 2.20GHz
Vitesse du processeur en MHz : 1468.843
Vitesse maximale du processeur en MHz : 3100,0000
Cache L1d :32K
Cache L1i : 32K
Cache L2 : 256K
Cache L3 : 25600K
```
### Description de la démarche systématique
Description de la démarche systématique et de l'espace d'exploration pour chaque paramètres:
Description de la démarche systématique et de l'espace d'exploration pour chaque paramètre:
Afin d'obtenir les données nécessaires à la génération des graphiques, il est nécessaire de generer un
fichier de valeur (.csv), que l'on obtient en éxecutant un scrpit, prenant en paramètre simplement le nombre de répétitions des opérations
Afin d'obtenir les données nécessaires à la génération des graphiques, il est nécessaire de générer un fichier de valeur (.csv), que l'on obtient en exécutant un script, prenant en paramètre simplement le nombre de répétitions des opérations
Script utilisé:
```sh
...
...
@@ -113,24 +109,32 @@ done
### 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.
Au niveau de la consommation de mémoire ainsi que du temps d'exécution, on constate que plus le nombre d'opération augmente, plus le temps d'exécution ainsi que la consommation mémoire augmente de façon exponentielle. On peut expliquer cela par le fait que nous avons fait le choix de recréer une array pour chaque élément ajouté / inséré. Par exemple, si l'on décide d'ajouter une valeur à un tableau de 50 éléments, on va créer un tableau de 51 élément vide auquel on rajoute les 50 éléments du tableau précèdent ainsi que la valeur souhaitée. On constate également que le temps d'exécution est fortement lié à la génération de nombre aléatoire. On observe une croissance logarithmique en fonction du nombre de répétition
```java
//Extrait du code pour la fonction insertHead() de Array
int[]tempArray=array;
array=newint[size];
//Insertion des valeurs dans le nouveau tableau
array[0]=elem;
for(inti=1;i<size;i++){
array[i]=tempArray[i-1];
}
```
En ce qui concerne les autres structures, on remarque que les insertions en tête pour la structure ArrayList sont plus lente que pour la structure linkedlist car une insertion dans une arraylist nécessite de modifier l'index de chacun des éléments alors qu'une liste doublement chainée (dans notre cas) ne nécessite de modifier que 2 valeurs.
### 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.
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. Une des limites concernant les résultats obtenus sur nos graphiques sont lié au type array: En effet, lors des insertions de valeurs, on ne parvient pas à déterminer réellement le temps écoulé / la consommation de mémoire pour effectuer l'action d'insertion, puisque cette opération nécessite la recréation du tableau, ainsi que son insertion.
## Etude approfondie
### Hypothèse
Expression précise et succincte d'une hypothèse.
Notre hypothèse est que les pics d'utilisation de mémoire et de temps d'exécution sont dus au fait qu'à chaque ajout d'une valeur dans le tableau de taille n, nous devons recréer ce même tableau avec une taille de n+1 et donc copier l'intégralité du précédent tableau à chaque ajout de valeur.
### Protocole expérimental de vérification de l'hypothèse
Expression précise et succincte du protocole.
Afin d'améliorer les performances de l'application lors de l'utilisation de tableaux, nous allons faire en sorte que lorsque le tableau a atteint sa capacité maximale, un nouveau tableau est créé dont la taille correspond au double de celle du tableau précédent, au lieu de simplement l'augmenter de 1. Ainsi, plus le nombre de valeur contenu dans le tableau est élevé, moins il sera nécessaire de recréer le tableau
```
Suite des commandes, ou script, à exécuter pour produire les données.
