Discussion :

[Zapan]

Bonjour,

Je travaille sur une programme qui lance plusieurs processus :


Ceci lance des exécutables (écrit en c) qui réalisent des caluls très compliqués : plusieurs heure sd'éxécution, et qui affichent les résultats sans cesse dans la console.

Le temps d'exécution est donc primordiale, et l'éxécution est plus longue quand je lance ce programme depuis java que depuis le terminal.

Il y a t'il une raison à cela ?

Merci d'avance pour votre aide.

[jowo]

Le volume de données de la sortie standard est-il important?

Il se peut que la sortie des données ralentit ton programme C. En effet, la sortie est bloquante.

Commentaire:
Avec ton code, il ya une possibilité (peu probable) de blocage du programme C.
Imaginons le scénatio suivant, ton progamme génère un volume important sur le sortie d'erreur et la sortie standard. Le tampon de la sortie d'erreur se remplit car il n'est jamais lu. Et quand il sera plein, ton programme C se bloquera

[xavlours]

Le ralentissement n'est il pas simplement du au fait qu'un programme java tourne en meme temps ?

[jowo]

Le ralentissement n'est il pas simplement du au fait qu'un programme java tourne en meme temps ?

Normalement, le programme Java est bloqué sur la sortie standard. Quand une "chaîne de caractère" est disponible, il la lit et il l'affiche.

Remarque:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

resultat = new String(bufferedReaderInputStream.readLine());

Il n'est pas nécessaire d'instancier une nouveau String.

En plus, il se peut qu'à la première lecture, la méthode readLine() returne un null.

Correction:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
while ((resultat = new String(bufferedReaderInputStream.readLine()) != null) {
   System.out.println(resultat);
}

[Zapan]

Le volume de données de la sortie standard est-il important?

Oui, il est très important le programme affiche tous ses calculs, il affiche tellement que ca défile très vite dans la console.

Le tampon de la sortie d'erreur se remplit car il n'est jamais lu. Et quand il sera plein, ton programme C se bloquera

Mais je le lis tout le temps donc je ne pense pas que ca soit ca. De plus j'ai un ralentissement, pas un blocage.

Le ralentissement n'est il pas simplement du au fait qu'un programme java tourne en meme temps ?

J'ai lancé dans la console avec le programme java qui tourne a coté et eclipse : plein d'application bien lourde. Résultat, en ligne de commande c'est toujours plus rapide.

Il n'est pas nécessaire d'instancier une nouveau String.

En plus, il se peut qu'à la première lecture, la méthode readLine() returne un null.

Merci, j'ai corrigé.

Ce ne serais pas possible que ca soit du au flux important de donnée généré que j'affiche avec des println dans la console ?

[jowo]

Le volume de données de la sortie standard est-il important?

Oui, il est très important le programme affiche tous ses calculs, il affiche tellement que ca défile très vite dans la console.

Le tampon de la sortie d'erreur se remplit car il n'est jamais lu. Et quand il sera plein, ton programme C se bloquera

Mais je le lis tout le temps donc je ne pense pas que ca soit ca. De plus j'ai un ralentissement, pas un blocage.

Je parle d'une erreur possible. En effet, tu lis d'abord la sortie standard puis la sortie d'erreur. Le problème surviendrai si ton processus C écrit dans sa sortie d'erreur tandis que Java attend sagement des données sur la sortie standard.

Le ralentissement n'est il pas simplement du au fait qu'un programme java tourne en meme temps ?

J'ai lancé dans la console avec le programme java qui tourne a coté et eclipse : plein d'application bien lourde. Résultat, en ligne de commande c'est toujours plus rapide.

Beaucoup plus rapide?

Il n'est pas nécessaire d'instancier une nouveau String.

En plus, il se peut qu'à la première lecture, la méthode readLine() returne un null.

Merci, j'ai corrigé.

Ce ne serais pas possible que ca soit du au flux important de donnée généré que j'affiche avec des println dans la console ?

Ne serai-t-il pas envisageable d'écrire les données dans un fichier?

[Zapan]

Je parle d'une erreur possible. En effet, tu lis d'abord la sortie standard puis la sortie d'erreur. Le problème surviendrai si ton processus C écrit dans sa sortie d'erreur tandis que Java attend sagement des données sur la sortie standard.

Je ne peux pas lire dans les deux buffers à la fois. Mais j'ai utilisé des try ... catch pour ce cas là. Ce n'est pas suffisant ?

Beaucoup plus rapide?

Je ne sais pas avec précision, je vais mesurer.
Pour décrire lecomportement, le programme semble aller à une vitesse normal et au bout de quelques secondes s'arrête, et repart... ainsi de suite.

Ne serai-t-il pas envisageable d'écrire les données dans un fichier?

Ce serais possible je pense, et j'afficherais juste si il y a une erreur.

[adiGuba]

Salut,

Je ne peux pas lire dans les deux buffers à la fois. Mais j'ai utilisé des try ... catch pour ce cas là. Ce n'est pas suffisant ?

Non ce n'est pas suffissant et cela peut te poser des problèmes comme cela a été dit...
Les flux sortant des applications lancé par Runtime.exec() sont copier dans des buffers (pas très grand, et cela dépend de la JVM).
Si un de ces buffers est plein, l'application sera bloqué en écriture jusqu'à ce que ce buffer soit lu.

Donc dans ton cas si ton programme écrit trop de caractères dans le flux d'erreur, cela risque de tout bloqué :

• Ton application en C attendra que le buffer stderr soit lu pour continuer.
• Ton application Java attendra que ton programme C soit fini pour sortir de la boucle de lecture de stdout.

Bref chacun de tes programmes est en attente de l'autre...

Pour éviter cela il faut lire le flux d'erreur dans un thread séparé...

Note : je ne pense pas que ce soit l'origine de ton problème car cela provoque un vrai blocage, mais c'est important de gérer cela car cela peut éviter de se demander pourquoi le programme bloque en cas d'erreur



Autre remarque : tu ne fermes pas tes flux ce qui n'est pas très propre...




Enfin ton problème vient surement du fait que tu utilises la méthode readLine() de BufferedReader. En effet pour chaque ligne que tu lit, un nouvel objet String sera crée.

Si comme tu le dit le programme génère un grand nombre de ligne, tu te retrouve avec un grand nombre d'objet instancié, et donc une grosse consommation mémoire. Le comportement que tu décris semble correspondre à un passage forcé du Garbage Collector car il n'y a plus de mémoire disponible (il libère toutes les instances de String que tu as crée, d'où une perte de temps assez conséquente).


Pour remédier à cela il faudrait que tu utilises le même objet en mémoire pour lire les données... surtout que tu te contentes de renvoyer les données dans le flux de sortie de ton application...


Ce qui pourrait donner :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
	protected void dumpStreamAndClose (InputStream in, OutputStream out) {
		try {
			byte[] buffer = new byte[1024];
			int read;
 
 
			while ( (read = in.read(buffer) )>=0) {
				out.write(buffer, 0, read);
			}
 
		} catch (IOException lException) {
			// TODO Auto-generated catch block
			lException.printStackTrace();
		} finally {
			try {
				in.close();
			} catch (IOException lException) {
				lException.printStackTrace();
			}
		}
 
	}
 
 
	private int executeCommande (String[] commande) {
 
 
		File repertoireTravail = new File(cheminAppli);   
		final Process process1;
		try {
			process1 = Runtime.getRuntime().exec(commande, null, repertoireTravail);
		} catch (IOException lException1) {
			// TODO Auto-generated catch block
			lException1.printStackTrace();
			return -1;
		}
 
		new Thread() {
			public void run() {
				dumpStreamAndClose(process1.getErrorStream(), System.err);
			}
		}.start();
 
		dumpStreamAndClose(process1.getInputStream(), System.out);
 
		boolean ended = false;
		while (!ended) {
			try {
				process1.waitFor();
				ended = true;
			} catch (InterruptedException lException) {
				// on gère le cas ou l'attente est interrompue...
			}
		}
 
		int error = process1.exitValue();
		if (error != 0){	
			System.out.println(" $   Erreur numero : " + error + "\n $   Fin de la simulation.\n");
		}
		return error;
 
	}

La méthode dumpStreamAndClose() copie un flux dans un autre en utilsiant directement un buffer de byte, afin d'éviter d'allouer de la mémoire à chaque lecture. Le Thread permet de lire le flux stderr en parallele...

Enfin il est preferable d'entourer le waitFor() par une boucle afin d'être sûr que le process est bien terminé (la méthode peut être intérrompue alors que le programme n'est pas forcément terminé).

Sur une commande qui dure 3 secondes avec ta méthode, je gagne environ une seconde comme cela...

a++

[edit] je viens de m'apercevoir d'un petit oubli... Il faudrait fermet le flux stdin si on ne l'utilise pas. Un simple process.getOutputStream().close() devrait faire l'affaire...