Emploi répété de la classe URL

Version imprimable

Bonjour,

J'exploite la classe URL pour ouvrir successivement différentes pages web.

Actuellement, j'ai une succession d'éléments crées à chaque fois que j'en
ai besoin (voir code ci-joint).

Le problème c'est que j'éxécute ces lignes de plus en plus souvent et
j'aimerais faire l'économie des constructeurs new à chaque fois.
Je cherche donc à créer une fois pour toutes mes objets URL, InputStreamReader, etc.

Mais alors, j'ai découvert par exemple qu'on ne peut pas créer un URL(null) et qu'il faut forcément lui assigner une URL (que je ne connais pas en amont
du programme) donc je lui assigne une adresse du type URL("http://www.liberation.fr") pour que l'objet se crée.

Plus gênant, la fonction set prend plusieurs arguments alors que j'aurais aimé un simple url.set("http:www.nouveausite.com").

Comment vous faites vous pour gérer ce type d'emploi répété de la classe URL ?
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 url = new URL(PageURL); InPStream = new InputStreamReader(url.openStream()); BufferedReader Breader = new BufferedReader(InPStream); BufferedWriter Bwriter=null; FileWriter Bfile=null; Bfile = new FileWriter("PagePrincipale.html"); Bwriter = new BufferedWriter(Bfile); while ((line = Breader.readLine()) != null) { Bwriter.write(line); Bwriter.newLine(); contents.append(line); } Breader.close(); Bwriter.close(); InPStream.close();

24/09/2009, 14h39
adiGuba

Salut,

Citation:

Envoyé par devroot

j'aimerais faire l'économie des constructeurs new à chaque fois.

Pourquoi ?

a++
24/09/2009, 15h11
devroot

adiGuba tu ne penses pas que c'est un problème alors....

Et si ces lignes sont éxécutées, je sais pas... 300 fois en une minute.
C'est pas du travail en plus pour la machine que d'allouer de la mémoire à
chaque fois.
Enfin, je me demande si c'est pas mieux d'allouer une fois au début puis
de changer les paramètres des objets plusieurs fois ?

fausse bonne idée : l'optimiseur d'exécution sait faire mieux que toi

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
 
public class TrucDePerf {
	private long lA ;
	private long lB ;
	public TrucDePerf() {}
	public TrucDePerf(long l1, long l2) {
		lA = l1 ;
		lB = l2 ;
	}
 
	public void setAll(long l1, long l2) {
		lA = l1 ;
		lB = l2 ;
	}
 
	public static void main(String[] args) {
		Random rd = new Random() ;
 
		long timer = System.currentTimeMillis() ;
		TrucDePerf truc = new TrucDePerf() ;
		for(int ix = 0 ; ix < 1000000 ; ix++){
			long lx = rd.nextLong() ;
			long ly = rd.nextLong() ;
			truc.setAll(lx, ly);
		}
 
		long timer2 = System.currentTimeMillis() ;
		System.out.println(" difference avec set " + (timer2 - timer));
		timer = System.currentTimeMillis() ;
		for(int ix = 0 ; ix < 1000000 ; ix++){
			long lx = rd.nextLong() ;
			long ly = rd.nextLong() ;
			new TrucDePerf(lx, ly);
		}
		timer2 = System.currentTimeMillis() ;
		System.out.println(" difference avec constructeur " + (timer2 - timer));
	}
 
}

résultat des courses :
difference avec set 234
difference avec constructeur 203

(edit: bon c'est pas tout à fait exact car il y a pénalité pour le premier qui commence mais l'idée est là, plusieurs essais ne donnent pas les mêmes perfs
- j'ai par ex 141 187- mais c'est pas trop un gros problème ... je pense que les gains n'en valent pas la chandelle )

24/09/2009, 16h52
devroot

Ah oui alors ça c'est sans appel...

Merci beaucoup Professeur Shadoko, le point est
désormais clarifié pour moi.
24/09/2009, 16h59
adiGuba
Citation:

Envoyé par devroot

adiGuba tu ne penses pas que c'est un problème alors....

Non : au contraire cela permet d'avoir un code bien lisible et des objets avec une durée de vie bien limité !

Citation:

Envoyé par devroot

C'est pas du travail en plus pour la machine que d'allouer de la mémoire à chaque fois.

Le GC alloue la mémoire à l'avance, et c'est particulièrement performant dans les cas où on utilise plusieurs objets...
- En C/C++ par exemple cela serait très couteux car il y aurait une allocation/désallocation par objet.
- En Java la création/destruction d'un objet est nettement moins couteuse car le GC se contente la plupart du temps à initialiser une zone mémoire déjà alloué.
Citation:

Envoyé par devroot

Enfin, je me demande si c'est pas mieux d'allouer une fois au début puis de changer les paramètres des objets plusieurs fois ?

Cela augmente le scope de l'objet et sa durée de vie, ce qui peut gêner au travail du GC : en clair tu vas conserver des références sur des objets dont tu n'as plus l'utilité, simplement pour conserver la zone mémoire pour plus tard... :arrow: c'est ce que fait le GC ! Sauf qu'il le fait pour tous les objets...

Bref pour moi cela n'a pas trop d'intérêt... à moins de travailler sur un environnement avec une mémoire très réduite...

Il serait plus utile de bien étudier le choix du scope des objets, et de libérer proprement les ressources externes !!!

Citation:

Envoyé par professeur shadoko

(edit: bon c'est pas tout à fait exact car il y a pénalité pour le premier qui commence mais l'idée est là, plusieurs essais ne donnent pas les mêmes perfs mais c'est pas trop un gros problème)

+1 c'est ce que j'allais dire lorsque j'ai vu ton edit ;)

:arrow: Il faut toujours boucler plusieurs fois afin d'avoir une moyenne, car les premiers passages peuvent être faussé par la compilation JIT...

De même faire attention au passage du GC (avec -verbose:gc) et à bien obtenir une différence de temps significatif (quitte à augmenter le nombre d'iteration) : dans de nombreux système currentTimeMillis() n'est mis à jour que toutes les 16ms environ. Ce qui fait qu'on peut avoir une erreur allant jusqu'à 32ms...

a++