Ralentissements importants sur une une appli java/swing
15 réponses
Glop
Bonjour
J'ai une appli écrite en java/swing et utilisant des tas de librairies, avec
un code pas parfaitement optimisé. Tout cela la fait déjà ramer pas mal mais
jusqu'ici c'était tenable.
L'IHM permet d'ouvrir une série de boîtes de dialogue qui sont toutes
construites suivant un schéma identique. A leur "tête", une classe mère java
permettant de créer dynamiquement la boîte qui m'intéresse avec son contenu
(champs de saisie, combos...). Chaque boîte de dialogue la dérive ensuite
pour son propre compte.
A la création, certaines boîtes seulement bouffent une mémoire pas possible
(jusqu'à 80Mo la première fois) alors que la grande majorité des autres
gratte 1Mo à tout casser. Cette mémoire n'est pas restituée à la fermeture
et au coup d'après environ 20 à 30Mo de plus sont utilisés et ainsi de
suite.
Les recherches ont mis en évidence que l'exécution de la méthode pack() à
elle seule prenait presque 30s. Cette méthode se trouve dans la classe mère
de toutes les fenêtres. Il est impossible de s'en passer.
Qui aurait une explication sur le fait que seules certaines fenêtres (avec
beaucoup de contenu mais il y en a d'autres) utilisent autant de mémoire à
cause de cette méthode (ou autre ?) ?
Sachant qu'on utilise java 1.5.08, que le problème a été résolu en mettant
des options de réservation mémoire dans la commande java sur PC mais que
l'application devant tourner aussi sur SunOS, cette optimisation ne
fonctionne pas . En effet la mémoire totale utilisée par l'appli (Résultat
donné par la commande 'top') plafonne à une valeur insuffisante alors qu'il
en reste pourtant pas mal de disponible, c'est peut-être du au système
comment savoir...
Autres tentatives effectuées: remplacer l'appel à pack(), utiliser le gc(),
en vain. Je n'ai pas non plus d'outil de mesures à disposition.
Les recherches ont mis en évidence que l'exécution de la méthode pack() à elle seule prenait presque 30s. Cette méthode se trouve dans la classe mère de toutes les fenêtres. Il est impossible de s'en passer.
Qui aurait une explication sur le fait que seules certaines fenêtres (avec beaucoup de contenu mais il y en a d'autres) utilisent autant de mémoire à cause de cette méthode (ou autre ?) ?
Tu pourrais mettre une capture d'écran de chaque fenêtre quelque part sur un site, avec pour chacune le temps que tu as mesuré ?
Sachant qu'on utilise java 1.5.08, que le problème a été résolu en mettant des options de réservation mémoire dans la commande java sur PC mais que l'application devant tourner aussi sur SunOS, cette optimisation ne fonctionne pas . En effet la mémoire totale utilisée par l'appli (Résultat donné par la commande 'top') plafonne à une valeur insuffisante alors qu'il en reste pourtant pas mal de disponible, c'est peut-être du au système comment savoir...
Autres tentatives effectuées: remplacer l'appel à pack(), utiliser le gc(), en vain. Je n'ai pas non plus d'outil de mesures à disposition.
Ca c'est un peu facheux, parce qu'à mon avis un petit coup de JProfiler pourrait peut-être expliquer un peu plus précisément les choses.
-- Christophe Franco
Glop <glop@glop.fr> wrote:
Les recherches ont mis en évidence que l'exécution de la méthode pack() à
elle seule prenait presque 30s. Cette méthode se trouve dans la classe mère
de toutes les fenêtres. Il est impossible de s'en passer.
Qui aurait une explication sur le fait que seules certaines fenêtres (avec
beaucoup de contenu mais il y en a d'autres) utilisent autant de mémoire à
cause de cette méthode (ou autre ?) ?
Tu pourrais mettre une capture d'écran de chaque fenêtre quelque part
sur un site, avec pour chacune le temps que tu as mesuré ?
Sachant qu'on utilise java 1.5.08, que le problème a été résolu en mettant
des options de réservation mémoire dans la commande java sur PC mais que
l'application devant tourner aussi sur SunOS, cette optimisation ne
fonctionne pas . En effet la mémoire totale utilisée par l'appli (Résultat
donné par la commande 'top') plafonne à une valeur insuffisante alors qu'il
en reste pourtant pas mal de disponible, c'est peut-être du au système
comment savoir...
Autres tentatives effectuées: remplacer l'appel à pack(), utiliser le gc(),
en vain. Je n'ai pas non plus d'outil de mesures à disposition.
Ca c'est un peu facheux, parce qu'à mon avis un petit coup de JProfiler
pourrait peut-être expliquer un peu plus précisément les choses.
Les recherches ont mis en évidence que l'exécution de la méthode pack() à elle seule prenait presque 30s. Cette méthode se trouve dans la classe mère de toutes les fenêtres. Il est impossible de s'en passer.
Qui aurait une explication sur le fait que seules certaines fenêtres (avec beaucoup de contenu mais il y en a d'autres) utilisent autant de mémoire à cause de cette méthode (ou autre ?) ?
Tu pourrais mettre une capture d'écran de chaque fenêtre quelque part sur un site, avec pour chacune le temps que tu as mesuré ?
Sachant qu'on utilise java 1.5.08, que le problème a été résolu en mettant des options de réservation mémoire dans la commande java sur PC mais que l'application devant tourner aussi sur SunOS, cette optimisation ne fonctionne pas . En effet la mémoire totale utilisée par l'appli (Résultat donné par la commande 'top') plafonne à une valeur insuffisante alors qu'il en reste pourtant pas mal de disponible, c'est peut-être du au système comment savoir...
Autres tentatives effectuées: remplacer l'appel à pack(), utiliser le gc(), en vain. Je n'ai pas non plus d'outil de mesures à disposition.
Ca c'est un peu facheux, parce qu'à mon avis un petit coup de JProfiler pourrait peut-être expliquer un peu plus précisément les choses.
-- Christophe Franco
Hervé AGNOUX
J'ai l'impression que vous nous demandez plus un travail de pompier... En effet, ce n'est pas swing qui met 30 secondes à exécuter un pack ; il doit y avoir un incendie quelque part.
Lors d'un pack, swing - ou awt, d'ailleurs - calcule la taille idéale des différents composants des fenêtres, à partir de leur contenu et du mode de disposition choisi. Cette méthode provoque donc une intense activité processeur, puisqu'il y a à la fois chargement de contenu et calcul de dimensions.
Pour que cela prenne moins de temps, des pistes :
- quel est ce contenu que je charge, et est-il possible que cela prenne 3 plombes ? - aider le calcul en fixant les tailles des composants, par divers moyens, selon le layout choisi (fixer size, prefferedSize, etc, etc, etc). - ne pas appeler pack ! - etc.
Bon courage.
Glop wrote:
Bonjour
J'ai une appli écrite en java/swing et utilisant des tas de librairies, avec un code pas parfaitement optimisé. Tout cela la fait déjà ramer pas mal mais jusqu'ici c'était tenable. [...]
-- Hervé AGNOUX http://www.diaam-informatique.com
J'ai l'impression que vous nous demandez plus un travail de pompier... En
effet, ce n'est pas swing qui met 30 secondes à exécuter un pack ; il doit
y avoir un incendie quelque part.
Lors d'un pack, swing - ou awt, d'ailleurs - calcule la taille idéale des
différents composants des fenêtres, à partir de leur contenu et du mode de
disposition choisi. Cette méthode provoque donc une intense activité
processeur, puisqu'il y a à la fois chargement de contenu et calcul de
dimensions.
Pour que cela prenne moins de temps, des pistes :
- quel est ce contenu que je charge, et est-il possible que cela prenne 3
plombes ?
- aider le calcul en fixant les tailles des composants, par divers moyens,
selon le layout choisi (fixer size, prefferedSize, etc, etc, etc).
- ne pas appeler pack !
- etc.
Bon courage.
Glop wrote:
Bonjour
J'ai une appli écrite en java/swing et utilisant des tas de librairies,
avec un code pas parfaitement optimisé. Tout cela la fait déjà ramer pas
mal mais jusqu'ici c'était tenable.
[...]
J'ai l'impression que vous nous demandez plus un travail de pompier... En effet, ce n'est pas swing qui met 30 secondes à exécuter un pack ; il doit y avoir un incendie quelque part.
Lors d'un pack, swing - ou awt, d'ailleurs - calcule la taille idéale des différents composants des fenêtres, à partir de leur contenu et du mode de disposition choisi. Cette méthode provoque donc une intense activité processeur, puisqu'il y a à la fois chargement de contenu et calcul de dimensions.
Pour que cela prenne moins de temps, des pistes :
- quel est ce contenu que je charge, et est-il possible que cela prenne 3 plombes ? - aider le calcul en fixant les tailles des composants, par divers moyens, selon le layout choisi (fixer size, prefferedSize, etc, etc, etc). - ne pas appeler pack ! - etc.
Bon courage.
Glop wrote:
Bonjour
J'ai une appli écrite en java/swing et utilisant des tas de librairies, avec un code pas parfaitement optimisé. Tout cela la fait déjà ramer pas mal mais jusqu'ici c'était tenable. [...]
-- Hervé AGNOUX http://www.diaam-informatique.com
Glop
Tu pourrais mettre une capture d'écran de chaque fenêtre quelque part sur un site, avec pour chacune le temps que tu as mesuré ?
Comme c'est pour le boulot je ne suis pas sûre d'en avoir le droit...
Ca c'est un peu facheux, parce qu'à mon avis un petit coup de JProfiler pourrait peut-être expliquer un peu plus précisément les choses.
Je vais tenter ma chance auprès de ceux qui gèrent les sousous... ;-)
Tu pourrais mettre une capture d'écran de chaque fenêtre quelque part
sur un site, avec pour chacune le temps que tu as mesuré ?
Comme c'est pour le boulot je ne suis pas sûre d'en avoir le droit...
Ca c'est un peu facheux, parce qu'à mon avis un petit coup de JProfiler
pourrait peut-être expliquer un peu plus précisément les choses.
Je vais tenter ma chance auprès de ceux qui gèrent les sousous... ;-)
Tu pourrais mettre une capture d'écran de chaque fenêtre quelque part sur un site, avec pour chacune le temps que tu as mesuré ?
Comme c'est pour le boulot je ne suis pas sûre d'en avoir le droit...
Ca c'est un peu facheux, parce qu'à mon avis un petit coup de JProfiler pourrait peut-être expliquer un peu plus précisément les choses.
Je vais tenter ma chance auprès de ceux qui gèrent les sousous... ;-)
cfranco
Glop wrote:
Tu pourrais mettre une capture d'écran de chaque fenêtre quelque part sur un site, avec pour chacune le temps que tu as mesuré ?
Comme c'est pour le boulot je ne suis pas sûre d'en avoir le droit...
Le problème, c'est que ma boule de cristal est en panne, je pense qu'elle doit avoir besoin d'être reformatée, mais en attendant que je le fasse je vais avoir du mal à t'aider si j en'ai aucun élément...
Ca c'est un peu facheux, parce qu'à mon avis un petit coup de JProfiler pourrait peut-être expliquer un peu plus précisément les choses.
Je vais tenter ma chance auprès de ceux qui gèrent les sousous... ;-)
Ca vaudrait largement le coût, je ne suis pas un fana des logiciels commerciaux, je travaille à 99% avec des outils libres, mais JProfiler est le seul qui me semble être réellement tellement incontournable que ça vaille le coup de l'acheter. Parce qu'avec ça tu gagnes incontestablement des jours et des jours de travail, et aussi parce que en libre il n'y a pas grand chose qui tienne la route...
Eventuellement, si le budget n'est pas là, tu peux jeter un oeil à ce projet : http://ejp.sourceforge.net/
-- Christophe Franco
Glop <glop@glop.fr> wrote:
Tu pourrais mettre une capture d'écran de chaque fenêtre quelque part
sur un site, avec pour chacune le temps que tu as mesuré ?
Comme c'est pour le boulot je ne suis pas sûre d'en avoir le droit...
Le problème, c'est que ma boule de cristal est en panne, je pense
qu'elle doit avoir besoin d'être reformatée, mais en attendant que je le
fasse je vais avoir du mal à t'aider si j en'ai aucun élément...
Ca c'est un peu facheux, parce qu'à mon avis un petit coup de JProfiler
pourrait peut-être expliquer un peu plus précisément les choses.
Je vais tenter ma chance auprès de ceux qui gèrent les sousous... ;-)
Ca vaudrait largement le coût, je ne suis pas un fana des logiciels
commerciaux, je travaille à 99% avec des outils libres, mais JProfiler
est le seul qui me semble être réellement tellement incontournable que
ça vaille le coup de l'acheter. Parce qu'avec ça tu gagnes
incontestablement des jours et des jours de travail, et aussi parce que
en libre il n'y a pas grand chose qui tienne la route...
Eventuellement, si le budget n'est pas là, tu peux jeter un oeil à ce
projet :
http://ejp.sourceforge.net/
Tu pourrais mettre une capture d'écran de chaque fenêtre quelque part sur un site, avec pour chacune le temps que tu as mesuré ?
Comme c'est pour le boulot je ne suis pas sûre d'en avoir le droit...
Le problème, c'est que ma boule de cristal est en panne, je pense qu'elle doit avoir besoin d'être reformatée, mais en attendant que je le fasse je vais avoir du mal à t'aider si j en'ai aucun élément...
Ca c'est un peu facheux, parce qu'à mon avis un petit coup de JProfiler pourrait peut-être expliquer un peu plus précisément les choses.
Je vais tenter ma chance auprès de ceux qui gèrent les sousous... ;-)
Ca vaudrait largement le coût, je ne suis pas un fana des logiciels commerciaux, je travaille à 99% avec des outils libres, mais JProfiler est le seul qui me semble être réellement tellement incontournable que ça vaille le coup de l'acheter. Parce qu'avec ça tu gagnes incontestablement des jours et des jours de travail, et aussi parce que en libre il n'y a pas grand chose qui tienne la route...
Eventuellement, si le budget n'est pas là, tu peux jeter un oeil à ce projet : http://ejp.sourceforge.net/
-- Christophe Franco
Glop
J'ai l'impression que vous nous demandez plus un travail de pompier... En effet, ce n'est pas swing qui met 30 secondes à exécuter un pack ; il doit y avoir un incendie quelque part.
L'incendie c'est très possible, sinon j'avais posté dans l'hypothèse que quelqu'un aurait déjà rencontré ce problème quelque part. C'est une appli dont j'ai récupéré la maintenance et mon expérience java n'est pas encore très importante.
- quel est ce contenu que je charge, et est-il possible que cela prenne 3 plombes ?
Le chargement en tant que tel peut-être pas (lecture d'un petit fichier xml) mais sa redistribution dans l'arbre DOM associé sans doute.
- aider le calcul en fixant les tailles des composants, par divers moyens, selon le layout choisi (fixer size, prefferedSize, etc, etc, etc).
Déjà fait mais pas probant pour l'instant. Ces fenêtres sont construites en utilisant un ZoneLayout.
- ne pas appeler pack !
Dans ce cas on obtient un petit rectangle qu'il faut redimensionner à la main pour voir apparaître tous les champs. Ce n'est pas envisageable.
- etc.
Il y a sans doute un vice caché dans un code qui n'est certainement pas assez optimisé (la conception s'est faite en même temps que la réalisation...) donc ma vraie question en fait serait: a-t'on constaté des anomalies de ralentissement dans cette version de java ? Je me suis laissé dire que oui mais sans autre précision.
Bon courage.
Merci
J'ai l'impression que vous nous demandez plus un travail de pompier... En
effet, ce n'est pas swing qui met 30 secondes à exécuter un pack ; il doit
y avoir un incendie quelque part.
L'incendie c'est très possible, sinon j'avais posté dans l'hypothèse que
quelqu'un aurait déjà rencontré ce problème quelque part. C'est une appli
dont j'ai récupéré la maintenance et mon expérience java n'est pas encore
très importante.
- quel est ce contenu que je charge, et est-il possible que cela prenne 3
plombes ?
Le chargement en tant que tel peut-être pas (lecture d'un petit fichier xml)
mais sa redistribution dans l'arbre DOM associé sans doute.
- aider le calcul en fixant les tailles des composants, par divers moyens,
selon le layout choisi (fixer size, prefferedSize, etc, etc, etc).
Déjà fait mais pas probant pour l'instant.
Ces fenêtres sont construites en utilisant un ZoneLayout.
- ne pas appeler pack !
Dans ce cas on obtient un petit rectangle qu'il faut redimensionner à la
main pour voir apparaître tous les champs. Ce n'est pas envisageable.
- etc.
Il y a sans doute un vice caché dans un code qui n'est certainement pas
assez optimisé (la conception s'est faite en même temps que la
réalisation...) donc ma vraie question en fait serait: a-t'on constaté des
anomalies de ralentissement dans cette version de java ? Je me suis laissé
dire que oui mais sans autre précision.
J'ai l'impression que vous nous demandez plus un travail de pompier... En effet, ce n'est pas swing qui met 30 secondes à exécuter un pack ; il doit y avoir un incendie quelque part.
L'incendie c'est très possible, sinon j'avais posté dans l'hypothèse que quelqu'un aurait déjà rencontré ce problème quelque part. C'est une appli dont j'ai récupéré la maintenance et mon expérience java n'est pas encore très importante.
- quel est ce contenu que je charge, et est-il possible que cela prenne 3 plombes ?
Le chargement en tant que tel peut-être pas (lecture d'un petit fichier xml) mais sa redistribution dans l'arbre DOM associé sans doute.
- aider le calcul en fixant les tailles des composants, par divers moyens, selon le layout choisi (fixer size, prefferedSize, etc, etc, etc).
Déjà fait mais pas probant pour l'instant. Ces fenêtres sont construites en utilisant un ZoneLayout.
- ne pas appeler pack !
Dans ce cas on obtient un petit rectangle qu'il faut redimensionner à la main pour voir apparaître tous les champs. Ce n'est pas envisageable.
- etc.
Il y a sans doute un vice caché dans un code qui n'est certainement pas assez optimisé (la conception s'est faite en même temps que la réalisation...) donc ma vraie question en fait serait: a-t'on constaté des anomalies de ralentissement dans cette version de java ? Je me suis laissé dire que oui mais sans autre précision.
Bon courage.
Merci
TestMan
Tu pourrais mettre une capture d'écran de chaque fenêtre quelque part sur un site, avec pour chacune le temps que tu as mesuré ?
Comme c'est pour le boulot je ne suis pas sûre d'en avoir le droit...
Ca c'est un peu facheux, parce qu'à mon avis un petit coup de JProfiler pourrait peut-être expliquer un peu plus précisément les choses.
Je vais tenter ma chance auprès de ceux qui gèrent les sousous... ;-)
Bonjour,
Si c'est une application critique, il est indispensable que tu obtiennes cette license (ou celles d'un outils équivalent). Dans les grands groupes il y a souvent des licenses "flotantes" pour les outils de tests et diagnostic, renseignes toi auprès du groupe ad-hoc (rien à voir avec le capitaine).
Une fois que tu auras analysés le comportement, tu auras certainement la révélation du "pourquoi" : - il y a des ensembles d'objets qui ne sont pas époussetés (en clair, "qui les tiens" et empèche le ramasse-miètte de faire son taf) - certaines méthodes prennent 3 plombes - des boites consome 80MO
Bonne découverte ...
A+ TM
Tu pourrais mettre une capture d'écran de chaque fenêtre quelque part
sur un site, avec pour chacune le temps que tu as mesuré ?
Comme c'est pour le boulot je ne suis pas sûre d'en avoir le droit...
Ca c'est un peu facheux, parce qu'à mon avis un petit coup de JProfiler
pourrait peut-être expliquer un peu plus précisément les choses.
Je vais tenter ma chance auprès de ceux qui gèrent les sousous... ;-)
Bonjour,
Si c'est une application critique, il est indispensable que tu obtiennes
cette license (ou celles d'un outils équivalent). Dans les grands
groupes il y a souvent des licenses "flotantes" pour les outils de tests
et diagnostic, renseignes toi auprès du groupe ad-hoc (rien à voir avec
le capitaine).
Une fois que tu auras analysés le comportement, tu auras certainement la
révélation du "pourquoi" :
- il y a des ensembles d'objets qui ne sont pas époussetés (en clair,
"qui les tiens" et empèche le ramasse-miètte de faire son taf)
- certaines méthodes prennent 3 plombes
- des boites consome 80MO
Tu pourrais mettre une capture d'écran de chaque fenêtre quelque part sur un site, avec pour chacune le temps que tu as mesuré ?
Comme c'est pour le boulot je ne suis pas sûre d'en avoir le droit...
Ca c'est un peu facheux, parce qu'à mon avis un petit coup de JProfiler pourrait peut-être expliquer un peu plus précisément les choses.
Je vais tenter ma chance auprès de ceux qui gèrent les sousous... ;-)
Bonjour,
Si c'est une application critique, il est indispensable que tu obtiennes cette license (ou celles d'un outils équivalent). Dans les grands groupes il y a souvent des licenses "flotantes" pour les outils de tests et diagnostic, renseignes toi auprès du groupe ad-hoc (rien à voir avec le capitaine).
Une fois que tu auras analysés le comportement, tu auras certainement la révélation du "pourquoi" : - il y a des ensembles d'objets qui ne sont pas époussetés (en clair, "qui les tiens" et empèche le ramasse-miètte de faire son taf) - certaines méthodes prennent 3 plombes - des boites consome 80MO
Bonne découverte ...
A+ TM
Glop
Le problème, c'est que ma boule de cristal est en panne, je pense qu'elle doit avoir besoin d'être reformatée, mais en attendant que je le fasse je vais avoir du mal à t'aider si j en'ai aucun élément...
Ben oui je sais mais bon... Je n'attendais pas de miracle non plus. Mais on ne sait jamais, ça aurait pu correspondre à un problème connu.
Eventuellement, si le budget n'est pas là, tu peux jeter un oeil à ce projet : http://ejp.sourceforge.net/
Merci pour le tuyau?
Le problème, c'est que ma boule de cristal est en panne, je pense
qu'elle doit avoir besoin d'être reformatée, mais en attendant que je le
fasse je vais avoir du mal à t'aider si j en'ai aucun élément...
Ben oui je sais mais bon... Je n'attendais pas de miracle non plus. Mais on
ne sait jamais, ça aurait pu correspondre à un problème connu.
Eventuellement, si le budget n'est pas là, tu peux jeter un oeil à ce
projet :
http://ejp.sourceforge.net/
Le problème, c'est que ma boule de cristal est en panne, je pense qu'elle doit avoir besoin d'être reformatée, mais en attendant que je le fasse je vais avoir du mal à t'aider si j en'ai aucun élément...
Ben oui je sais mais bon... Je n'attendais pas de miracle non plus. Mais on ne sait jamais, ça aurait pu correspondre à un problème connu.
Eventuellement, si le budget n'est pas là, tu peux jeter un oeil à ce projet : http://ejp.sourceforge.net/
Merci pour le tuyau?
Glop
Si c'est une application critique, il est indispensable que tu obtiennes cette license (ou celles d'un outils équivalent). Dans les grands groupes il y a souvent des licenses "flotantes" pour les outils de tests et diagnostic, renseignes toi auprès du groupe ad-hoc (rien à voir avec le capitaine).
Une fois que tu auras analysés le comportement, tu auras certainement la révélation du "pourquoi" : - il y a des ensembles d'objets qui ne sont pas époussetés (en clair, "qui les tiens" et empèche le ramasse-miètte de faire son taf) - certaines méthodes prennent 3 plombes - des boites consome 80MO
Bonne découverte ...
Merci, je vais demander aux moules-à-gaufres qui gèrent le budget ;-)
Si c'est une application critique, il est indispensable que tu obtiennes
cette license (ou celles d'un outils équivalent). Dans les grands groupes
il y a souvent des licenses "flotantes" pour les outils de tests et
diagnostic, renseignes toi auprès du groupe ad-hoc (rien à voir avec le
capitaine).
Une fois que tu auras analysés le comportement, tu auras certainement la
révélation du "pourquoi" :
- il y a des ensembles d'objets qui ne sont pas époussetés (en clair, "qui
les tiens" et empèche le ramasse-miètte de faire son taf)
- certaines méthodes prennent 3 plombes
- des boites consome 80MO
Bonne découverte ...
Merci, je vais demander aux moules-à-gaufres qui gèrent le budget ;-)
Si c'est une application critique, il est indispensable que tu obtiennes cette license (ou celles d'un outils équivalent). Dans les grands groupes il y a souvent des licenses "flotantes" pour les outils de tests et diagnostic, renseignes toi auprès du groupe ad-hoc (rien à voir avec le capitaine).
Une fois que tu auras analysés le comportement, tu auras certainement la révélation du "pourquoi" : - il y a des ensembles d'objets qui ne sont pas époussetés (en clair, "qui les tiens" et empèche le ramasse-miètte de faire son taf) - certaines méthodes prennent 3 plombes - des boites consome 80MO
Bonne découverte ...
Merci, je vais demander aux moules-à-gaufres qui gèrent le budget ;-)
Hervé AGNOUX
Glop wrote:
Le chargement en tant que tel peut-être pas (lecture d'un petit fichier xml) mais sa redistribution dans l'arbre DOM associé sans doute.
Si c'est un petit fichier XML (inférieur à 100 Ko), je doute que ce soit ça. Peux-tu faire un essai avec un fichier complètement vide (ou au minimum ? )
- ne pas appeler pack !
Dans ce cas on obtient un petit rectangle qu'il faut redimensionner à la main pour voir apparaître tous les champs. Ce n'est pas envisageable.
Oui mais dans ce cas, est-ce que le temps d'affichage est le même ? Lors du redimenssionnement, est-ce que le réaffichage prend beaucoup de temps ?
-- Hervé AGNOUX http://www.diaam-informatique.com
Glop wrote:
Le chargement en tant que tel peut-être pas (lecture d'un petit fichier
xml) mais sa redistribution dans l'arbre DOM associé sans doute.
Si c'est un petit fichier XML (inférieur à 100 Ko), je doute que ce soit ça.
Peux-tu faire un essai avec un fichier complètement vide (ou au minimum ? )
- ne pas appeler pack !
Dans ce cas on obtient un petit rectangle qu'il faut redimensionner à la
main pour voir apparaître tous les champs. Ce n'est pas envisageable.
Oui mais dans ce cas, est-ce que le temps d'affichage est le même ? Lors du
redimenssionnement, est-ce que le réaffichage prend beaucoup de temps ?
Le chargement en tant que tel peut-être pas (lecture d'un petit fichier xml) mais sa redistribution dans l'arbre DOM associé sans doute.
Si c'est un petit fichier XML (inférieur à 100 Ko), je doute que ce soit ça. Peux-tu faire un essai avec un fichier complètement vide (ou au minimum ? )
- ne pas appeler pack !
Dans ce cas on obtient un petit rectangle qu'il faut redimensionner à la main pour voir apparaître tous les champs. Ce n'est pas envisageable.
Oui mais dans ce cas, est-ce que le temps d'affichage est le même ? Lors du redimenssionnement, est-ce que le réaffichage prend beaucoup de temps ?
-- Hervé AGNOUX http://www.diaam-informatique.com
Francis JUGE-BOIRARD
Je pense que vous n'êtes pas sur la bonne piste, il y a visiblement une fuite de mémoire mais je doute qu'elle soit due à Swing. Il est plus probable que l'appel de pack rame par ce qu'un autre process (chargement de données ???) prend énormément de temps. JProfiler serait sympa mais je pense qu'en posant des traces directement dans le code, il doit être possible de cerner plus précisément le problème.
Bon courage. J'ai vécu ça avec JDBC et j'en ai bavé avant d'obtenir le résultat attendu.
Francis JUGE-BOIRARD
Je pense que vous n'êtes pas sur la bonne piste, il y a visiblement une fuite de
mémoire mais je doute qu'elle soit due à Swing. Il est plus probable que l'appel
de pack rame par ce qu'un autre process (chargement de données ???) prend
énormément de temps.
JProfiler serait sympa mais je pense qu'en posant des traces directement dans le
code, il doit être possible de cerner plus précisément le problème.
Bon courage. J'ai vécu ça avec JDBC et j'en ai bavé avant d'obtenir le résultat
attendu.
Je pense que vous n'êtes pas sur la bonne piste, il y a visiblement une fuite de mémoire mais je doute qu'elle soit due à Swing. Il est plus probable que l'appel de pack rame par ce qu'un autre process (chargement de données ???) prend énormément de temps. JProfiler serait sympa mais je pense qu'en posant des traces directement dans le code, il doit être possible de cerner plus précisément le problème.
Bon courage. J'ai vécu ça avec JDBC et j'en ai bavé avant d'obtenir le résultat attendu.
