Discussion :

[MrDuChnok]

Bonjour,

J'aurai besoin de conseils vis à vis de l'optimisation de code.
Je dois lire un "gros" fichier texte d'environ 5Mo. Il est constitué d'environ 2000 lignes, dont certaines assez longues (> 4000 caractères).
Sur chacune de ces lignes sont encodées tous un tas de paramètres qui doivent être lus dans l'ordre d'écriture.
Sur une ligne, on va trouver des paramètres principaux séparés par un premier délimiteur. Pour chacun des paramètres principaux, il y a des paramètres secondaires séparées par un deuxième délimiteur. Et enfin pour chacun des paramètre secondaire, il y a des paramètres tertiaires séparés par un autre délimiteur.

Actuellement voici mon algo de lecture :
Pour tout le fichier :
Je lis une ligne.
J'utilise le split pour découper selon le 1 délimiteur.
Pour chacun des blocs obtenus, je redécoupe avec split pour le 2ème délimiteur.
Pour chacun des sous blocs, je (re)redécoupe avec split pour le 3ème délimiteur.


Dans un premier temps j'ai utilisé le String.split(). Après quelques recherches, je me suis rendu compte qu'il étais plus intéressant de précompiler le pattern de l'expression régulière et de la réutiliser à chaque fois (Pattern).

Maintenant je m'aperçois, via JProfiler que c'est cette dernière méthode qui est la plus gourmande dans mon algorithme. ça met environ 5sec à lire mon fichier, j'aimerai que ça descendre en dessous de la seconde, si c'est possible.
Avez vous des conseils d'optimisations à me donner ? (threader la lecture, changer la méthode de split, améliorer les expressions régulières, etc)
Voir même changer le format du fichier d'entrée si c'est vraiment pas jouable.

[adiGuba]

Salut,

Dans un premier temps j'ai utilisé le String.split(). Après quelques recherches, je me suis rendu compte qu'il étais plus intéressant de précompiler le pattern de l'expression régulière et de la réutiliser à chaque fois (Pattern).

En effet en règle général la création du Pattern est assez couteuse, alors que son utilisation l'est nettement moins.

Avez vous des conseils d'optimisations à me donner ? (threader la lecture, changer la méthode de split, améliorer les expressions régulières, etc)
Voir même changer le format du fichier d'entrée si c'est vraiment pas jouable.

Le threading apportera un amélioration seulement si tu es sur un bi-processeur ou un bi-coeur ou plus... et encore cela dépend car tu auras un surcoût lié à la synchronisation...


Pour t'aider davantage il faudrait avoir ton code et un échantillon du fichier...

a++

[jowo]

Bonjour,

Une voie d'amélioration est de ne pas utiliser de la classe String durant le traitement de ton fichier.

Je travaille actuellement sur un projet (Java 1.4) où le traitement se fait sur des fichiers texte > 100Mo avec des lignes d'environ 200 caractères. Le fichier parsé produit un autre fichier ~5Mo.

Je n'utilise que les classes StringBuffer, CharSequence et pour certains points les expression rationnelles. Je suis en dessous des 3s de traitement.

Le point de départ de mon idée de ne pas utiliser la Classe String est dû au fait que c'est une classe immuable. La lecture d'un fichier de 100Mo va générer la même quantité de données le GC devra libérer.

Je ne sais pas si la base de réflexion est correcte. Je n'ai pas fait de mesure donc tout est subjectif.

[adiGuba]

Le point de départ de mon idée de ne pas utiliser la Classe String est dû au fait que c'est une classe immuable. La lecture d'un fichier de 100Mo va générer la même quantité de données le GC devra libérer.

La classe String en elle même n'est pas un problème (d'ailleurs lorsque tu manipules des CharSequence il y a de forte chance que tu manipules en réalité des String). Il faut juste prendre conscience qu'il ne faut pas concaténer des String dans une boucle (voir la FAQ : Comment concatener des chaînes de caractères ?)

a++

[MrDuChnok]

voilà le goulot d'étranglement principale :

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
 
String[] listParam = patternDiese.split(p_string); //p_string.split("#");
for(String iteParam : listParam) {
	//On identifie le type de la valeur en fonction de la clé.
	int indexOfEqual = iteParam.indexOf("=");
	String keyStr = iteParam.substring(0, indexOfEqual);
	Integer keyInt = Integer.valueOf(keyStr);
	String valueStr = iteParam.substring(indexOfEqual + 1, iteParam.length() );
	switch(keyInt) {
 
	case 1:
 
		Double valueDou = Double.valueOf(valueStr);
		data.m_ListData.put(keyInt, valueDou);
		break;
 
	case 2 :
		Map<String, Integer> listVariousParam = new HashMap<String, Integer>();
 
		String[] listStrVariousParam = patternSep.split(valueStr);//  valueStr.split("¤");
		int indexOfFleche = -1;
		for(String variousParam : listStrVariousParam) {
			indexOfFleche = variousParam.indexOf("->");
		       String keyStrVariousParam = variousParam.substring(0, indexOfFleche);
 
			String valueStrVariousParam = variousParam.substring(indexOfFleche + 2, variousParam.length() );
 
			listVariousParam.put(keyStrVariousParam, Integer.valueOf(valueStrVariousParam));
		}
 
		data.m_ListData.put(keyInt, listVariousParam);
		break;
 
 
	}
}

Donc voilà où j'en suis. Je vais essayer d'explorer la piste des CharSequence peut être...

[jean.2edi]

Si ton délimiteur est simple, il vaudrait mieux éviter les expressions rationnelles et utiliser des recherches de chaînes ou caractère (ton # et ton ¤).

Ensuite, il faut effectivement éviter de fabriquer des chaines temporaires avec les morceaux de ce que tu as trouvé : gère plutôt une chaine de départ (ta ligne) sous forme de String ou CharSequence ou tableau de caractères ou de byte et des indices de début / fin.

Ce sera bien moins lisible mais plus efficace à mon avis...

[hibour]

Salut
La méthode String.split(regex) qui utilise la classe Pattern est moins performante que celle de StringUtils.split() de apache (commons-lang) qui utilise StringTokenizer.
Cdlt