bonjour,
Je suis débutant en java. J'aimerai vous soumettre un problème que j'ai. Je ne pense pas qu'il s'agisse d'un problème algorithmique mais bien un problème inhérent au langage JAVA.
voici l'histoire.
 
j'ai réalisé un programme qui sera amené a fonctionné sur un grand nombre de données de la façon suivante:
 
1) lecture d'un fichier
2) analyse du fichier
3) traitement  
 
Lors de ces trois phases, j'instancie un grand nombres d'objets.
 
l'exécution de ce programme prend environ 4.5 secondes lorsque je l'exécute sur un fichier.
 
J'ai ensuite essayé d'insérer une boucle for dans le main pour faire une moyenne du temps d'exécution :

voici ce que le programme genere comme sortie  :  

 
 diff correspond au temps d'exécution d'une boucle. On voit bien que le temps d'exécution crois très vite alors qu'il s'agit du même traitement exécuté 4 fois sur le même fichier
 
D'autre part, j'ai essayé par un script perl de lancer le programme sans la boucle for  :  

je constate alors que le temps d'exécution reste constant...
 
Comment cela ce fait il que le temps d'exécution augmente dans un cas et pas dans l'autre?????
Quelqu'un aurai-t-il une idée
Je vais être amené a traiter un grand nombre d'information et je ne souhaiterai pas avoir a utiliser un artifice tel que "lancer le programme avec un script perl"
Si quelqu'un pourrai me donner une piste cela m'aiderai beaucoup.
 
 
 

et si t'enleves ton appel à System.gc() ?

j'ai deja essayé mais rien ne change

sur un temps si court, ton timer n'est pas très représentatif ...
de la même façon, juste 4 tests, c'est pas suffisant non plus pour en tirer de conclusion ...
 
ensuite, comme on ne connait pas la nature du traitement que tu fais on ne peut pas t'en dire plus ...
mais par exemple, si HashMap contient de plus en plus de choses, c'est pas surprenant que le temps d'execution augmente puisqu'une recherche/ajout dedans sera de plsus en plus long ...

je remet la hashMap a null a chaque iteration de la boucle for
Elle ne stock les infos que temporarement.
Le traitement est un peut long mais je peut peut-etre le résumer ici:
1) je lis le fichier et j'en resors l'info
2) je ferme le fichier
3) les infos servent a creer un nouvel objet (graph)
4) j'opère des calcules sur ces objets (distances entre les points du graph)
5) je calcule une distribution (c'est peut compliqué mais sachez que je n'instancie aucun objet durant cette étape)
6) je strocke cette distribution a la fin
7) je remet les reférence a null pour la hashmap et le graph
8) je recommence
 
En réalité j'ai fais ce test a plus grande echelle mais les temps devenais trop long apres 10 iterations. En gros je double le temps entre 2 itération.
La chose la plus curieus est que je n'augmente pas ce temps si je lance le .jar a l'exterieur par un script perl ...

Ca peut être signe d'un beau leak

ouais, bha cherche pas plus loin, y a un truc dans ton traitement qui fait que tu reviens pas au conditions de départ à la fin de ton traitement ...

leak???

merci
mais je remet tous les objets instancier a null
du coup je pense que le garbage collecteur veins faire son affaire et il ne reste plus de données...
Or non! il reste quelque chose en mémoire ou un truc qui fais que les donnée mettent plus de temps a etre traitées. du coup remettre un objet a null n'est pas suffisant pour que le GC les ramasse???  
je pige pas du tout pk

fuite

Vérifie qu'une référence n'est pas gardée ailleurs, il ne suffit pas de mettre à null, d'où le leak possible

voila l'histoire
c une grosse boulette de ma pare:
j'ai crée une liste statique membre de classe. A chaque création d'un objet de cette classe, j'ajoute des données dans cette liste. Du coup les données restaient stockées en membre de classe et quand je parcoure ces données, la taille augmentais.
 
voila
moralité bien faire gaffe aux objets statiques....
heureusement que j'ai commencé par dire que j'étais un débutant:oops:  
merci a tous

Pour le .net, j'avais un chouette profiler qui t'affichais ce qui y avait en mémoire quand on le voulait, c'était très bien pour voir quels objets sont encore là