Discussion :

[maccormick]

Bonjour à tous,
Je suis en train de faire une application qui traite des listes de discussion.
J'ai donc un objet Projet, qui contient un tableau d'objets Liste.
Chaque objet Liste contient un tableau d'objets Message.
Chaque objet Message est constitué de 12 champs : nom, date, mail ... etc.
Tous ces objets sont sérialisés lors de chaque mise à jour de l'objet Projet ou Liste (Observer/Observable).

Je lance mes processus à l'aide de SwingWorkers:
- Lorsque j'ajoute une première liste et que j’extrais pour la première fois mettons 50000 messages, tout se déroule parfaitement, en un peu moins de 10 secondes.
- Mais lorsque je réitère le processus pour la seconde fois en ajoutant une nouvelle liste avec 50000 Messages, un ralentissement énorme se fait vers 90%.
- Et lorsque le processus parvient enfin à se terminer, je ne peux même pas dépasser les 2% pour l'ajout d'une troisième liste.

J'ai téléchargé Memory Analyser, mais je ne vois pas grand chose dans les fuites potentielles, à part bien sûr des ArrayList énormes (mes 50000 messages), des objets String sur-utilisés (normal je fonctionne beaucoup avec des String) ou équivalents (normal aussi, par exemple pour les titres de messages), et un Thread énorme, le dernier à avoir été lancé (ça je pense aussi que c'est normal vu qu'il est bloqué !)

Je me demande donc si :
- un objet qui contient 2 tableaux de 50000 objets de 10 champs, soit donc un million de champs, c'est trop pour JAVA ?
- j'ai abandonné les bases de données (H2) pour faire du tout objet et de la sérialisation car je pensais ça plus souple : faut-il que je fasse marche arrière (ça m'embêterai parce que j'avais eu des soucis de Heap Space avec les bdd) ?
- y-a-t-il d'autres outils (dans Eclipse notamment) qui pourraient me dire ce qui ne va pas ?
- lorsque je lance plusieurs SwingWorkers à la suite, ils devraient être exécutés les uns à la suite des autres non ? car j'en utilise lors de la sauvegarde (sérialisation) de mes objets, et en fait plusieurs se lancent en même temps (j'ai testé avec des fenêtres de jprogressbar indeterminate et il y en a 2 qui apparaissent en même temps) après le lancement du second processus puis se bloquent (lorsque je lance le 1er, tout va très vite et je n'en voit qu'une !).
- Et de fait, la sérialisation se passe mal car je ne peux pas désérialiser ensuite.
- Plus généralement sur les SwingWorkers : en fait je les ai utilisé car j'avais des soucis de mise à jour de ma progressbar d'extraction des messages. Ça marche très bien, mais fondamentalement je n'en ai pas vraiment besoin car je travaille séquentiellement (les traitements que je fais après sur les messages ne peuvent se faire que si les messages ont été extraits !). Dons je me retrouve à lancer plein de SwingWorkers ... d'où peut-être le blocage ?
- avez-vous d'autres idées ?

[adiGuba]

Salut,

- un objet qui contient 2 tableaux de 50000 objets de 10 champs, soit donc un million de champs, c'est trop pour JAVA ?

Java n'a rien à voir là dedans, cela dépend de la taille des données et de la mémoire disponible pour la JVM...

Mais bon je ne sais pas si c'est très utile de tout charger en mémoire...

- j'ai abandonné les bases de données (H2) pour faire du tout objet et de la sérialisation car je pensais ça plus souple : faut-il que je fasse marche arrière (ça m'embêterai parce que j'avais eu des soucis de Heap Space avec les bdd) ?

Pourtant les BDD sont faites pour gérer simplement de grosse quantité de données...

- y-a-t-il d'autres outils (dans Eclipse notamment) qui pourraient me dire ce qui ne va pas ?

Dans le JDK tu as jvisualvm...

- lorsque je lance plusieurs SwingWorkers à la suite, ils devraient être exécutés les uns à la suite des autres non ? car j'en utilise lors de la sauvegarde (sérialisation) de mes objets, et en fait plusieurs se lancent en même temps (j'ai testé avec des fenêtres de jprogressbar indeterminate et il y en a 2 qui apparaissent en même temps) après le lancement du second processus puis se bloquent (lorsque je lance le 1er, tout va très vite et je n'en voit qu'une !).

Non par défaut les SwingWorker utilisent un pool de 10 thread max. Donc tu peux avoir 10 SW en même temps.

Si tu veux éviter cela il faut les lancer via ton propre executor (voir la classe Executors)


a++

[maccormick]

Java n'a rien à voir là dedans, cela dépend de la taille des données et de la mémoire disponible pour la JVM...

Oui, c'est ce que je voulais dire ...

Mais bon je ne sais pas si c'est très utile de tout charger en mémoire...

Pour avoir un affichage fluide, c'est plutôt mieux non ?

Pourtant les BDD sont faites pour gérer simplement de grosse quantité de données...

ok, mais j'avais aussi des heap space avec ma BDD

Dans le JDK tu as jvisualvm...

oui, j'ai regardé, et je suis bien en heap space, mais ce qui prend le plus de place, ce sont les char, String, int etc ...

Non par défaut les SwingWorker utilisent un pool de 10 thread max. Donc tu peux avoir 10 SW en même temps.

Si tu veux éviter cela il faut les lancer via ton propre executor (voir la classe Executors)

ok, du coup ça doit aller

Pour la BDD, tu peux me dire en gros à partir de quand, combien tu l'utilises ?

[hwoarang]

- Lorsque j'ajoute une première liste et que j’extrais pour la première fois mettons 50000 messages, tout se déroule parfaitement, en un peu moins de 10 secondes.
- Mais lorsque je réitère le processus pour la seconde fois en ajoutant une nouvelle liste avec 50000 Messages, un ralentissement énorme se fait vers 90%.
- Et lorsque le processus parvient enfin à se terminer, je ne peux même pas dépasser les 2% pour l'ajout d'une troisième liste.

Ca, ca sent la saturation mémoire ou bien le tri d'une grosse liste pas adaptée.

- un objet qui contient 2 tableaux de 50000 objets de 10 champs, soit donc un million de champs, c'est trop pour JAVA ?

Comme précisé, ca depend de la taille allouée à ta JVM. Mais dans tous les cas, c'est pas adapté (le probleme que tu rencontres se produit à 50000 messages mais qu'arrivera t-il a 100000 ou bien 150000 messages ?)

- j'ai abandonné les bases de données (H2) pour faire du tout objet et de la sérialisation car je pensais ça plus souple : faut-il que je fasse marche arrière (ça m'embêterai parce que j'avais eu des soucis de Heap Space avec les bdd) ?

C'est la solution qui te permettrai d'etre sur que ton programme marche quel que soit la quantité de données (et qui en plus est adaptée pour les extraire). Bref, c'est LA solution.

- y-a-t-il d'autres outils (dans Eclipse notamment) qui pourraient me dire ce qui ne va pas ?

+1 pour jvisualvm qui est pas mal.

- lorsque je lance plusieurs SwingWorkers à la suite, ils devraient être exécutés les uns à la suite des autres non ? car j'en utilise lors de la sauvegarde (sérialisation) de mes objets, et en fait plusieurs se lancent en même temps (j'ai testé avec des fenêtres de jprogressbar indeterminate et il y en a 2 qui apparaissent en même temps) après le lancement du second processus puis se bloquent (lorsque je lance le 1er, tout va très vite et je n'en voit qu'une !).

Le principe de swing, c'est d'avoir une seule tache (appelée EDT) qui manipule l'ensemble de l'IHM (affichage des composants graphiques et appel des listeners des composants d'interface comme les boutons ou les combos). Pour ne pas ralentir celle-ci, il n'y a pas de protection par semaphore des composants graphiques. C'est pour ca qu'il peut y avoir des exceptions quand tu ajoutes des elements dans une liste dans un thread que tu as créé. swingworker permet d'effectuer un traitement long sans bloquer l'ihm et, eventuellement, de la mettre à jour de temps en temps (principe de la progressbar). Pour finir, quel que soit le nombre de swingworkers utilisés, cette classe te garantie que l'appel des fonctions de l'ihm (cad les fonctions process et done) se fera dans le contexte de la tache EDT (donc par définition pas en meme temps).

[maccormick]

Bon, après analyse avec jvisualvm, c'est bien une saturation mémoire, et maintenant après quelques modifs, ça passe en heap space lors de la sérialisation !
Je vais donc me re-tourner vers H2, et prier pour que ça se passe bien cette fois : j'avais eu des galères avec lorsque je lui donnais un trop grand nombre de données, mais bon, je pense (j'espère ) que c'était un défaut de conception !!!
Merci et @+

[hwoarang]

Une base de données est beaucoup mieux foutue que tout ce que tu pourras faire pour stocker tes données (qui reviendra de toute facon à créer ton propre moteur de BDD, cad réinventer la roue). En plus, il en existe des bien foutues et gratuites (mysql ou hsqldb par exemple). C'est également le meilleur moyen d'etre sur que ton programme fonctionnera encore quand le nombre de messages aura augmenté (par définition, si tu crées des objets, il arrivera toujours un moment ou tu vas saturer ta mémoire). Avec une BDD, le risque est de saturer le disque, ce qui arrivera moins vite

[tchize_]

s it'as eu des problème de mémoire avec h2 c'est soit

- que tu a créé une base de données en mémoire, ce qui n'est pas très utilise pour la conservation des données, et ne résoud pas ton problème mémoire
- soi qu'en plus de les envoyer dans h2 t'a aussi continué à garder tes objet en mémoire.

H2, avec une empreinte java d'à peine quelques M est capable de gérer des base de plusieurs centaines de milliers de lignes sans soucis. Ne pas oublier de créer les index pour faire des recherches rapides dedans (ça peut faire la différence entre un select de quelques millisecondes et un select de 30 secondes :p )

[maccormick]

@hwoarang : oui, c'est vrai, surtout que je commençais justement dans mes traitements à faire des trucs super compliqués qu'un simple SELECT avec ORDER BY réalisait sans problème !

@tchize_ : salut tchize ! effectivement, je vais revoir ma conception d'appel de mes données. Mais par exemple, j'avais un heap space lorsque je devais mettre en mémoire tous mes messages pour les afficher dans un JTable. Dans ce cas là, je suis bien obligé de faire un SELECT * sur toute ma table non ?