temps d'execution qui augmente

temps d'execution qui augmente - Java - Programmation

Marsh Posté le 03-11-2006 à 11:51:28    

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 :

Code :
  1. public static void main(String[] args) {
  2.  //un parseur de fichier
  3.  CustomFileReader fic = null;
  4.  //une structure de donnée pour stocker l'info
  5.  HashMap<String, Double> infos=null;
  6.  for (int i = 0 ; i < 4; i ++ ){
  7.   long debut =System.nanoTime()/1000000000;
  8.   long fin =0;
  9.   System.out.println( "debut : "+debut ) ;
  10.   fic = null;
  11.   infos = null;
  12.   1) lecture du fichier
  13.          2) analyse du fichier
  14.                         3) traitement
  15.   System.gc();
  16.   fin = System.nanoTime()/1000000000;
  17.   System.out.println( "fin : "+fin  ) ;
  18.   System.out.println( "diff : "+(fin-debut)  ) ;
  19.  }
  20.  System.exit(0);
  21. }


voici ce que le programme genere comme sortie  :  

Citation :

debut : 1162548161
 
fin : 1162548166
diff : 5
debut : 1162548166
 
fin : 1162548183
diff : 17
debut : 1162548183
 
fin : 1162548219
diff : 36
debut : 1162548219
 
fin : 1162548282
diff : 63


 
 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  :  

Code :
  1. #!/usr/bin/perl
  2. for($i = 0 ; $i <4 ; $i++){
  3.        System("time java - jar test.jar" );
  4. }


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.
 
 
 

Reply

Marsh Posté le 03-11-2006 à 11:51:28   

Reply

Marsh Posté le 03-11-2006 à 12:10:20    

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


---------------
Posté depuis des chiottes, sales. Me gusta.
Reply

Marsh Posté le 03-11-2006 à 12:16:09    

boulax a écrit :

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


j'ai deja essayé mais rien ne change

Reply

Marsh Posté le 03-11-2006 à 13:20:32    

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 ...

Reply

Marsh Posté le 03-11-2006 à 14:11:04    

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 ...

Reply

Marsh Posté le 03-11-2006 à 14:11:22    

Ca peut être signe d'un beau leak

Reply

Marsh Posté le 03-11-2006 à 14:26:04    

naweill a écrit :


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 ...


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 ...

Reply

Marsh Posté le 03-11-2006 à 15:01:04    

FlorentG a écrit :

Ca peut être signe d'un beau leak


leak???

Reply

Marsh Posté le 03-11-2006 à 15:04:03    

benou a écrit :

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 ...


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

Reply

Marsh Posté le 03-11-2006 à 15:04:26    

fuite


---------------
HFR - Mes sujets pour Chrome - Firefox - vérifie les nouveaux posts des topics suivis/favoris
Reply

Marsh Posté le 03-11-2006 à 15:04:26   

Reply

Marsh Posté le 03-11-2006 à 15:07:34    

naweill a écrit :

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


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

Reply

Marsh Posté le 03-11-2006 à 15:33:52    

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

Reply

Marsh Posté le 03-11-2006 à 15:35:42    

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à

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed