Comment optimiser le GC pour allocation mémoire des images?

je suis en train de charcher le moyen d'optimiser les capacités du Garbage Collector afin d'accélérer le chargement de ressources Image dans une application. Sachant que j'utilise plus de 1000 resources images, je les charge préalablement grâce à un cache permettant le "swap" des ressources sur disque. Cela fonctionne parfaitement jusqu'à la 500-600e ressource, puis la boucle de chargement se fige rapidement en attendant le passage du GC.
J'ai passé les variables contenant les images à "volatile", j'ai passé les Threads à MAX_PRIORITY pour éviter d'être surchargé par le Thread normal du GC et aussi je les ai activé en mode Daemon.

Ma question est:
Comment optimiser la rapidité sur une telle structure Java? L'application tourne jusqu'à 600 images en cache avec 1024M de RAM pour Java. J'aimerais pouvoir dépasser cette limitation.
8O
le schéma est le suivant pour le chargement des resources: http://www.developpez.net/forums/att...1&d=1172167673

Tu peux utiliser les WeakReference. ça libère les ressources quand le système a besoin de place. Je ne sais pas si c'est ce dont tu as besoin.

Salut,

Citation:

---

Envoyé par broumbroum

J'ai passé les variables contenant les images à "volatile",

---

En quoi cela concerne-t-il ton problème ???

Citation:

---

Envoyé par broumbroum

j'ai passé les Threads à MAX_PRIORITY pour éviter d'être surchargé par le Thread normal du GC et aussi je les ai activé en mode Daemon.

---

Je ne pense pas que changer la priorité soit vraiment utile si le GC travaille trop... Quand au mode daemon j'avoue ne pas comprendre...

Citation:

---

Ma question est:
Comment optimiser la rapidité sur une telle structure Java? L'application tourne jusqu'à 600 images en cache avec 1024M de RAM pour Java. J'aimerais pouvoir dépasser cette limitation.

---

8O
le schéma est le suivant pour le chargement des resources: http://www.developpez.net/forums/att...1&d=1172167673[/QUOTE]


Que fais ton cache exactement ? Et les 600 images sont chargé en même temps ? Ca représentent quelle quantité de mémoire ???


a++

Citation:

---

Envoyé par adiGuba

(...)

Que fais ton cache exactement ? Et les 600 images sont chargé en même temps ? Ca représentent quelle quantité de mémoire ???


a++

---

ben justement c'est ma question... sachant que les images sont stockées en ".png", elle font 4Ko d'espace chacune. Si je les passes au 0.3x zoom (la résolution des images varie selon le mode d'affichage, spécifiquement l"ow", "mid" ou "high"): 1.6ko seulementen low resolution.
Mais je remarque évidemment que lors du chargement en mémoire physique la compression disparaît et ça passe à ~200Ko en 1x zoom, je pense 66Ko env. en "low res", car ImageIO donne le format traditionnel en "bits-map".
Plus précisément, je reformule la question: Est-ce possible de compresser les Graphics? OpenGL sait le faire? ou Zip?:fessee:

Il y a beaucoup de choses qui me font penser qu'il y a un bug quelque part dans ton code, ou que tu n'as pas compris quelque chose.

Ainsi quand tu demandes si Est-ce possible de compresser les Graphics? la réponse est forcément non : un Graphics est un objet très ponctuel, destiné uniquement à allumer des pixels sur un périphérique - image, imprimante, écran. Il n'est pas pensable de le comprimer, c'est comme si tu demandais s'il était possible de comprimer une socket.

Et dans l'ensemble tes principes me semblent bons ; je ne vois pas pourquoi cela ne fonctionnerait pas ; si ton système de swap est bon, il n'y a pas de raison que le gc passe trois plombes à nettoyer les objets.

Première piste, peut être : fais-tu bien les dispose de tes Graphics ? C'est l'erreur classique alors il faut tenter :D

Ensuite, analyse ton code pour voir s'il n'y a pas un endroit où les objets s'accumulent, sans être libérables. Eventuellement fait intervenir un profiler.

Et tiens nous au courant.

Citation:

---

Envoyé par gifffftane

(...)
Ainsi quand tu demandes si Est-ce possible de compresser les Graphics? la réponse est forcément non : un Graphics est un objet très ponctuel, destiné uniquement à allumer des pixels sur un périphérique - image, imprimante, écran. Il n'est pas pensable de le comprimer, c'est comme si tu demandais s'il était possible de comprimer une socket.
(...)

---

ben c est sur que ca met trop de temps. je ne vais pas attendre 15 min pour pouvoir commencer a jouer (c une plate-forme de jeu, cela dit)!!! du coup je me tourne vers la crompression des pixels justement pour eviter l usage onereux de memoire ram. sachant que les jeux demandent plus de rapidité, il faut le meilleur de Java pour obtenir ce que lon veut.
Alors peut-etre que l API traditonnelle est encore insuffisante, c pourquoi je cherche une librairie plus specifque. Particulierement, j ai deja essaye JAI pour la conversion des flux images, et ca tourne plus vite avec les fonctions JAI que ImageIO originale.
Par exemple, "Image multi-converter", une de mes applications présentes, c efficace. je gagne en tout cas 30 % de perfs avec le cache. Tout cela sans pour autant modifier le code, uniquement les fonctions clefs de l application, tel le Thread de conversion de format graphique.
voilà! donc JAI java advanced imaging 8O est à envisager pour le chargement des images.:salut:

le code du cache est ici sur DVP. mais ce serait plutot celui des Srites graphique que je modifierai... :D