Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
1704 connectés 

  FORUM HardWare.fr
  Programmation
  Java

  temps d'execution qui augmente

 


 Mot :   Pseudo :  
 
Bas de page
Auteur Sujet :

temps d'execution qui augmente

n°1469848
naweill
Posté le 03-11-2006 à 11:51:28  profilanswer
 

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.
 
 
 

mood
Publicité
Posté le 03-11-2006 à 11:51:28  profilanswer
 

n°1469867
boulax
Inserer phrase hype en anglais
Posté le 03-11-2006 à 12:10:20  profilanswer
 

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


---------------
Posté depuis des chiottes, sales. Me gusta.
n°1469876
naweill
Posté le 03-11-2006 à 12:16:09  profilanswer
 

boulax a écrit :

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


j'ai deja essayé mais rien ne change

n°1469934
benou
Posté le 03-11-2006 à 13:20:32  profilanswer
 

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

n°1470002
naweill
Posté le 03-11-2006 à 14:11:04  profilanswer
 

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

n°1470003
FlorentG
Posté le 03-11-2006 à 14:11:22  profilanswer
 

Ca peut être signe d'un beau leak

n°1470033
benou
Posté le 03-11-2006 à 14:26:04  profilanswer
 

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

n°1470105
naweill
Posté le 03-11-2006 à 15:01:04  profilanswer
 

FlorentG a écrit :

Ca peut être signe d'un beau leak


leak???

n°1470117
naweill
Posté le 03-11-2006 à 15:04:03  profilanswer
 

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

n°1470118
brisssou
8-/
Posté le 03-11-2006 à 15:04:26  profilanswer
 

fuite


---------------
HFR - Mes sujets pour Chrome - Firefox - vérifie les nouveaux posts des topics suivis/favoris
mood
Publicité
Posté le 03-11-2006 à 15:04:26  profilanswer
 

n°1470125
FlorentG
Posté le 03-11-2006 à 15:07:34  profilanswer
 

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

n°1470171
naweill
Posté le 03-11-2006 à 15:33:52  profilanswer
 

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

n°1470173
FlorentG
Posté le 03-11-2006 à 15:35:42  profilanswer
 

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à


Aller à :
Ajouter une réponse
  FORUM HardWare.fr
  Programmation
  Java

  temps d'execution qui augmente

 

Sujets relatifs
Souci à l'execution de softs écrits en c# + directx managed 2.0[CSS] Empêcher l'exécution d'un @import?
Sessions qui ne durent pas dans le tempsExecution de commande
En combien de temps ?Ecrire Paramètres Application à l'éxécution en fichier conf XML
Processeur d'exécutiontemps de reponse
Ouvrir deux page en même temps 
Plus de sujets relatifs à : temps d'execution qui augmente


Copyright © 1997-2022 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR