Discussion :

[nonoRedDevils]

Bonjour tout le monde!
Je developpe une application sur J2me avec Netbeans, elle a pour but d'afficher des images au format png qu'un serveur lui envoie.
Je suis confronté à de serieux problemes de performances.
J'ai repris cette application avant, pour la lecture des données (via un InputStream), on lisait octet par octet. Forcement c'etait plus lent, mais par contre ca n'obligeait pas d'allouer un tableau d'octet.
En effet pour faire le lien un ByteArrayOutPutstream et un InputStream, je n'ai trouvé qu'un tableau de byte [].
Dans ma version actuelle, j'alloue ce dernier à une taille maximal 100Ko (les images ne doivent pas depasser cette taille, le maximum qu ej'ai vu c'etait 77Ko).
Je l'utilise donc comme tampon, mon algo :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
-allocation : byte[] tabByte = new byte[1024*100]
-ouverture de la connection et des flux
-intanciation : ByteArrayOutputStream baStream = new ByteArrayOutputStream()
-gestion du protocole ....
-reception des images :
    - lecture segmentée des données, on ne peut pas tout lire en une seule instruction 
    - les données lues à chaque boucle sont stockée temporairement dans tabByte
    - puis elles sont insérées dans baStream
-creation de l'image avec Image.createImage (baStream.toByteArray())

Mon probleme c'est que mon appli est vraiment trop gourmande, j'ai donc essayé de limité au mieux mes "depenses" en :
- virant tous les message de debug (consommation de String)
- tous les variables locales qui sont utilisées dans les methodes sont mise à "null"

et j'ai dernierement essayé en lancant moi meme le Garbage Collector avec System.gc(), toutes les 100 images recues.
Dans l'emulateur du WKT25, dans le moniteur de gestion de la memoire, je me retrouve avec un beau signal triangulaire (blagues d'electronicien ), alors que sans j'ai droit à une succession d'exponentielles.

Ma question est simple, est ce que l'on peut / doit faire mieux ?
L'appel au Garbage Collector est-il conseillé?

Merci !

[adiGuba]

Salut,

Ma question est simple, est ce que l'on peut / doit faire mieux ?

Il faudrait surtout qu'on puisse voir ton code...

L'appel au Garbage Collector est-il conseillé?

Non... Je pense que tu ne devrais pas avoir à te soucier de l'appeler...

a++

[nonoRedDevils]

Salut,
Il faudrait surtout qu'on puisse voir ton code...

malheureusement je ne peux pas le mettre, je bosse pour une boite, j'ai demandé à ma chef qui me l'a interdit.

Non... Je pense que tu ne devrais pas avoir à te soucier de l'appeler...
a++

dans l'emulateur, je vois que la jvm fait appel à lui quand la memoire utilisée arrive à un seuil critique, ca pose un probleme si je le fais moi meme avant d'atteindre ce seuil ?

[adiGuba]

[QUOTE=nonoRedDevils]malheureusement je ne peux pas le mettre, je bosse pour une boite, j'ai demandé à ma chef qui me l'a interdit.

dans l'emulateur, je vois que la jvm fait appel à lui quand la memoire utilisée arrive à un seuil critique, ca pose un probleme si je le fais moi meme avant d'atteindre ce seuil ?

Non... mais le GC devrait tourner de lui même lorsque c'est nécessaire.
Le fait d'appeler toi même le GC ne rendra pas ton application moins gourmande...

• Quel est le protocole utilisé pour récupérer les images ? Ne te permet-il pas de connaitre la taille du fichier avant de commencer la lecture ? Cela te permettrait d'optimiser le ByteArrayOutputStream afin d'éviter qu'il ne se redimensionne plusieurs fois...
• De même, cela te permettrait d'utiliser directement un byte[] à la place de ByteArrayOutputStream, ce qui serait avantageux car toByteArray() crée un nouveau tableau en copie. Cela te permettrait également de faire une lecture directe...
• Il faudrait également voir si les variables temporaires de la boucle ne pourraient pas être évité...

Bref... Il faudrait bien voir l'algo et le code (et ce que cela implique en création d'objet temporaire) avant de se tourner vers le GC !

Si l'appli est gourmande c'est surement parce que le GC est déjà en train de allouer/libérer beaucoup d'objet... Donc l'appeler directement n'améliorera pas forcément les perfs (cela peut même avoir l'effet inverse).

Bon courage...

a++

[nonoRedDevils]

• Quel est le protocole utilisé pour récupérer les images ? Ne te permet-il pas de connaitre la taille du fichier avant de commencer la lecture ? Cela te permettrait d'optimiser le ByteArrayOutputStream afin d'éviter qu'il ne se redimensionne plusieurs fois...
  

• si je connais la taille du fichier que je dois recevoir, en gros je recois un message de 12 octets, qui contient la taille du bloc de donnée qui suit ce message
  
  

• De même, cela te permettrait d'utiliser directement un byte[] à la place de ByteArrayOutputStream, ce qui serait avantageux car toByteArray() crée un nouveau tableau en copie. Cela te permettrait également de faire une lecture directe...
• Il faudrait également voir si les variables temporaires de la boucle ne pourraient pas être évité...

[adiGuba]

si je connais la taille du fichier que je dois recevoir, en gros je recois un message de 12 octets, qui contient la taille du bloc de donnée qui suit ce message

Puisque tu connais la taille de l'image, tu peux optimiser ton tableau "bytearrayImg" afin qu'il n'utilise que ce qu'il a besoin :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

byte[] bytearrayImg = new byte[sizeData];

je n'utilise plus de ByteArrayOutputStream, à tord ?

Non : le ByteArrayOutputStream est très bien lorsque tu ne connais pas la taille exact de ce que tu vas lire, car il s'agrandit automatiquement et de manière transparente. Mais si tu connais la taille exacte c'est bien mieux de passer directement par un byte[]



Sinon : tu fermes bien tes InputStream ? Dans des bloc finally ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
InputStream in_stream = // ouverture du flux
try {
    // Traitements sur in_stream
} finally {
    in_stream.close();
}

a++

[nonoRedDevils]

Puisque tu connais la taille de l'image, tu peux optimiser ton tableau "bytearrayImg" afin qu'il n'utilise que ce qu'il a besoin :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

byte[] bytearrayImg = new byte[sizeData];

Non : le ByteArrayOutputStream est très bien lorsque tu ne connais pas la taille exact de ce que tu vas lire, car il s'agrandit automatiquement et de manière transparente. Mais si tu connais la taille exacte c'est bien mieux de passer directement par un byte[]

en fait, désolé je me suis mal exprimer, je connais certes la taille de l'image qui va arriver, mais les tailles sont toutes differentes!

Sinon : tu fermes bien tes InputStream ? Dans des bloc finally ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
InputStream in_stream = // ouverture du flux
try {
    // Traitements sur in_stream
} finally {
    in_stream.close();
}

a++

non je ne fais pas de close, car mon appli est fait de la video, donc si tu veux j'ai besoin que mon inputStream reste ouvert tant que l'utilisateur est connecté au site