[optimisation] problème de perf sur une boucle rs.next()

Version imprimable

Bonjour,

J'ai un gros problème de perf en essayant de lire beaucoup de lignes (200000) en base.
Le problème n'est pas dans la requête SQL, mais bien quand je remplie une ArrayList avec mon résultat.

Le code concerné :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 ------- ArrayList itemLst; ArrayList itemLstLst; // Lecture des informations while(rs.next()) { itemLst = new ArrayList(); itemLst.add(rs.getString("field1")); itemLst.add(rs.getString("field2")); /* ...*/ itemLst.add(rs.getString("field30")); itemLstLst.add(itemLst); } ------
Est-ce que quelqu'un sait comment optimiser ce code ?
Le traitement des données dans les listes après est lui performant et beaucoup plus rapide, bizarre...

19/06/2006, 10h40
in

pense à la balise code ...

je ne sais pas trop mais peut etre qu'initialisé la taille de ton arrayList à 200000 permettrait d'améliorer un peu les choses ....
19/06/2006, 10h46
jaaaaf

Citation:

Envoyé par in

pense à la balise code ...

Merci de l'avoir fait pour moi, je débute sur ce forum :oops:

Citation:

Envoyé par in

je ne sais pas trop mais peut etre qu'initialisé la taille de ton arrayList à 200000 permettrait d'améliorer un peu les choses ....

Le problème est que je n'ai aucune idée du nombre de ligne que je vais récupérer...
Et je ne crois pas (j'ai pas vu comment) récupérer le nombre de ligne rendue dans le ResultSet.
19/06/2006, 10h54
adiGuba
Salut,

Ton problème de performances (de quel ordre de temps s'agit-il ?) vient surement du fait que tu alloues beaucoup de mémoire :
- 200 000 ArrayList
- 6 000 000 de String
As-tu vraiment besoin de tout stocker avant d'effectuer tes traitements ? Tu obtiendrais surement de meilleurs résultats si tu effectueais tes traitements lignes par lignes...

Si ce n'est pas possibles, quelques pistes :
- Comme cela a été dit, tu peux initialiser tes ArrayList en spécifiant leurs tailles puisque. Cela t'éviteras que la taille du tableau soit réalloué (et donc une copie de tableau), mais également un gain de mémoire. Pour ton tableau global (itemLstLst) tu peux utiliser la solution de la FAQ : Comment connaître le nombre de lignes/colonnes d'un ResultSet ?
  Et tu peux faire la même chose pour tes ArrayList temporaire (itemLst) puisque la taille semble fixe (30)
- Si les valeurs qui te sont retourné par la BD sont souvent les mêmes, tu peux utiliser la méthode intern() de String pour éviter les doublons...
a++
19/06/2006, 10h59
jaaaaf

Merci pour les pistes, je regarde ça et je vous tiens au courant !
19/06/2006, 11h00
in

Citation:

Envoyé par jaaaaf

Merci de l'avoir fait pour moi, je débute sur ce forum :oops:

c'est pas moi, c'est wichtounet ;)
19/06/2006, 15h29
jaaaaf
J'ai fais des tests avec vos conseils, hélas pas trop de résultat :(
Le positionnement de ma liste à 30, et de ma liste de liste (positionné en dur) ne chage rien aux perfs.
En + je ne peux avoir le nombre de lignes puisque mon ResultSet est en TYPE_FORWARD_ONLY

Seul le String.intern() semble améliorer les perfs de 10%. C'est déjà ça, mais je suis encore loin de ce que je voudrai obtenir...

Je réponds aux questions de adiGuba.

Citation:

Envoyé par adiGuba

Ton problème de performances (de quel ordre de temps s'agit-il ?)

Ca reste relatif à la puissance du PC utilisé, mais en relatif ça donne ça :
- Temps de traitement de la requête (sur un serveur BD) 12s
- Temps de traitement de ma boucle 30s
- Temps de traitement et de création de tous les objet à partir de ma liste de liste : 3s! Le plus ettonnant est que dans ces créations d'objets, il est créé de nouveau plein de listes et pourtant ce n'est pas long !
Citation:

Envoyé par adiGuba

As-tu vraiment besoin de tout stocker avant d'effectuer tes traitements ? Tu obtiendrais surement de meilleurs résultats si tu effectueais tes traitements lignes par lignes...

Oui c'est sur.
Ca doit être possible de traiter ligne par ligne, mais il faut revoir tout le code derrière, et ça je voulais éviter parceque c'est un travail énorme !

Bref, si vous avez d'autres idées...
19/06/2006, 15h49
g_rare
Citation:
Envoyé par jaaaaf

Temps de traitement de la requête (sur un serveur BD) 12s
Pour moi le problème vient de la structure de ta requête : il est "irréaliste" de ramener 200.000 lignes de B.D. et d'en faire des calculs, sachant que des méthodes SQL comme <<count>> ou <<sum>> et des techniques de tri/filtrage comme <<order by>> ou <<where>> sont là pour ça !
Citation:
Envoyé par jaaaaf

Temps de traitement de ma boucle 30s
PS_ ça fait quand-même plus de 6000 lignes de ResultSet traitées par seconde ; c'est pas mal...

8O
19/06/2006, 15h56
jaaaaf
En fait, je viens de découvrir que le ResultSet ne récupère pas toutes les données en base et du coup c'est surtout le rs.next() qui est long car il récupère encore des données en base !
Le code suivant met 16s (sur mon PC) à s'exécuter, donc l'essentiel du temps passé dans ma boucle est pris par le rs.next()
Code:

1 2 3 4 5 while(rs.next()) { itemLst = null; }
Je vais investiguer sur le fetch du ResultSet.
19/06/2006, 16h01
jaaaaf

Citation:

Envoyé par g_rare

Pour moi le problème vient de la structure de ta requête : il est "irréaliste" de ramener 200.000 lignes de B.D. et d'en faire des calculs, sachant que des méthodes SQL comme <<count>> ou <<sum>> et des techniques de tri/filtrage comme <<order by>> ou <<where>> sont là pour ça !

Je suis tout a fait d'accord, mais je n'ai hélas pas vraiment le choix, c'est le client qui veut ça :(
Ma requête ne rapporte que les données utiles, elle fait déjà pas mal de lignes avec de belles parties where et order by...
19/06/2006, 16h04
in

daccord avec g_rare, il faut utiliser le plus possible les capacité de traitement de la BD. Elle est faite pour ça.

Sinon pour ton nombre de lignes, tu peux passer ton resultSet à scrollable non ?

pour la tailkle du fetch, ce que tu gagneras en temps de traitement, tu le perdra en mémoire je pense.

enfin, j'insiste mais tu devrais étudier le coté amont de l'histoire et passer par des vues ou des proc stockées (ou autre bien entendu).

[EDIT] OK, je retire vous ton précédent post, que nous avons écrit en meme temps ...
19/06/2006, 16h54
jaaaaf

Comme écrit dans : http://java.developpez.com/faq/jdbc/...esultset#fetch, j'ai positionné un fetch à 1000, et c'est beaucoup mieux !

C'est plus consomateur de mémoire, mais bien plus perf. La boucle (vide) passe de 16s à 4s.

Je suis pas encore au résultat espéré (au total), mais je progresse !