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.
Au niveau de la consomation de mémoire ainsi que du temps d'éxecution, on constate que plus le nombre d'opération augmente, plus le temps d'éxecution ainsi que la consomation mémoire augmente de facon expodentielle. On peut expliquer cela par le fait que nous avons fait le choix de recreer une array pour chaque élément ajouté / inséré. Par exemple, si l'on décide d'ajouter une valeur à un tableau de 50 élements, on va creer un tableau de 51 élément vide auquel on rajoute les 50 éléments du tableau précedent ainsi que la valeur souhaité.
On constate également que le temps d'éxecution 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;
...
...
@@ -130,6 +131,7 @@ for(int i = 1; i < size; i++) {
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 limite concernant les resultats obtenu sur nos graphiques sont lié au type array: En effet, lors des insertions de valeurs, on ne parvient pas à déterminer réelement le temps écoulé / la consomation de mémoire pour effectuer l'action d'insertion, puisque cette opération nécessite la recréation du tableau, ainsi que son insertion.
