Recyclage d'objets, performances

Je vais me lancer dans la conception d'un programme qui utilise plusieurs dizaines d'objets à la secondes.
Comme il devra fonctionner aussi bien sur PC que sur Android, j'ai besoin de très bonnes performances.

Plutôt que de créer les objets, j'ai lu qu'il était préférable de les "recycler".
C'est à dire que quand un objet n'est plus utiles, on le marque comme "à recycler", et on peut s'en resservir éventuellement plus tard (en y mettant de nouvelles informations).

Existe t-il quelque chose de prévu pour ça dans Java ?

Merci

bonjour,

Je ne pense pas qu'il y est quelque chose de prévu en java pour ça !
C'est à toi de prévoir le recyclage des objets.

Un très bon exemple de recyclage est celui des connexions JDBC grâce au pool de connexion.

Le principe est très simple : tu demandes une connexion au pool, s'il n'a pas de connexion dispo il en créé une sinon il t'en retourne une (déjà créé). Une fois le traitement terminé tu libères la connexion.

Heu...

En même temps c'est un peu ce que fais le GC : il réserve de la mémoire pour les futurs objets...

a++

ce genre de processus ne sera utile que si la création des objets et couteuse (connection à une base de donnée par exemple)

Pour le recyclage (et le pool) d'objet baisque, ca avait été tenté avec les EJB 2 en java. C'était extrèmement lourd et chiant à utiliser et le gain de performance n'a jamais été démontré. Entre remettre à zéro manuellement tous les champs d'un objet ou faire un new , je préfère la deuxième option. La jvm est capable de faire des centaines de new par seconde sans que tu t'en rende compte.

Citation:

---

Envoyé par adiGuba

Heu...

En même temps c'est un peu ce que fais le GC : il réserve de la mémoire pour les futurs objets...

a++

---

Oui ça je sait !
Sauf que ça prend un certain temps d'allouer de la mémoire.
Ce temps est minime la plupart du temps.
Mais dans mon cas, je vais avoir des dizaines d'objets par seconde.
Et c'est susceptible de tourner sur un téléphone Android.

ok pour le pool de connexion, je vais justement avoir un système un peu similaire.

je pense faire plusieurs choses :
- un constructeur privé sans paramètre
- une méthode getInstance prenant en paramètre ce que l'on fournit généralement à un constructeur
- une méthode recycle, s'occupant de recycler l'objet

Je pense aussi utiliser un tableau static contenant les objets "recyclés".

Je vois comment faire le mécanisme, le seul problème, c'est que j'en ai besoin dans plusieurs classes.
Ces classes héritent d'une classe commune, mais je ne vois pas trop comment faire pour hériter de ce système qui est essentiellement "static".

Citation:

---

Envoyé par tchize_

ce genre de processus ne sera utile que si la création des objets et couteuse (connection à une base de donnée par exemple)

Pour le recyclage (et le pool) d'objet baisque, ca avait été tenté avec les EJB 2 en java. C'était extrèmement lourd et chiant à utiliser et le gain de performance n'a jamais été démontré. Entre remettre à zéro manuellement tous les champs d'un objet ou faire un new , je préfère la deuxième option. La jvm est capable de faire des centaines de new par seconde sans que tu t'en rende compte.

---

Ha ?

J'avais fait une première version de mon logiciel n'utilisant pas le recyclage.
Je n'ai pas de problèmes de performances particuliers, mais je souhaite quand même le rendre le plus léger possible (Android oblige).

allouer / désallouer n'est pas si lourd que ca en java. Comme l'a dit adiguba, l'allocation "par bloc" est déjà gérée par la jvm. Quand tu fais un new, il va simplement localiser et "remettre à zéro" une zone mémoire qui lui appartiens déjà, dans la plus part des cas. Un code de recyclage aura plutot le problème inverse c'est qu'il va garder en mémoire plus que nécesaire, ce qui pourrait forcer la jvm à faire des allocations de mémoire supplémentaire inutiles.

As-tu déjà passé un profiler sur ton code pour prouver que l'allocation est un bottleneck? Passer son temps à optimiser un bout de code sans avoir, au préalable, la preuve que c'est lui qui consomme le plus de ressources et une perte de temps inutile. C'est un peut comme vouloir optimiser à tout prix l'injection dans un moteur à explosion pour accélérer la voiture et ne pas se rendre compte que depuis 2 ans on roule avec le frein à main serré ;)

Les profilers existent, utilise les.

Citation:

---

Envoyé par PierreD87

Sauf que ça prend un certain temps d'allouer de la mémoire.

---

En Java un new n'est pas synonyme d'allocation mémoire ! Le GC alloue la mémoire par bloc ;)


Je pense qu'il serait plus intéressant de connaitre la manière dont tu utilises tes objets...

a++

ok ok
Ce qui me fait surtout peur, c'est quand je regarde ma console DDMS (Android).

Sur certains programmes qui rament pas mal :
10-20 10:18:46.013: DEBUG/dalvikvm(144): GC freed 2894 objects / 156544 bytes in 111ms

Dans mon cas, la réactivité est cruciale

Citation:

---

Envoyé par adiGuba

En Java un new n'est pas synonyme d'allocation mémoire ! Le GC alloue la mémoire par bloc ;)


Je pense qu'il serait plus intéressant de connaitre la manière dont tu utilises tes objets...

a++

---

ça me sert à décrire un évènement de type interface utilisateur :
- souris
- clavier

Oui mais concrètement : comment tu les crées ? Pourquoi en utilises-tu autant ? etc...

As-tu réussi à cibler l'origine exact de ton problème de réactivité ?

a++

hahaha !
on dirait l'inquisition :)
"dis nous à quoi tu penses, on te dira pourquoi c'est mal !"
:)

Programme de contrôle à distance de mon PC depuis un téléphone Android.
ça fonctionne via udp.
uniquement souris et clavier pour le moment

Les objets crées me servent à décrire une action de contrôle.
Il y en a plusieurs type : mouvement souris, clic, roulette, clavier

Quand j'y repense, la création d'objets de ce type n'est pas forcément nécessaire sur un terminal Android, mais surtout côté "serveur/PC".
Donc je n'aurai peut être pas d'aussi gros problèmes de performances que je pensais.

Citation:

---

Envoyé par PierreD87

on dirait l'inquisition :)

---

Je dirais plutôt qu'il est difficile de te guider vers une solution très complexe sans rien connaitre de ton problème...

a++

Citation:

---

Envoyé par adiGuba

Je dirais plutôt qu'il est difficile de te guider vers une solution très complexe sans rien connaitre de ton problème...

a++

---

C'était dit sur un ton plein d'humour hein :)
Je trouve ça très bien comme fonctionnement !

ça a l'air de fonctionner sans recycler mes objets, même si j'ai plein de messages du type :
10-21 14:19:57.956: DEBUG/dalvikvm(10908): GC freed 4727 objects / 425688 bytes in 270ms

J'ai implémenté le recyclage sur un de mes objets.
Même si il est assez petit (16 octets),
ça doit quand même jouer un peu (il y en a 1 seul d'instancié au lieu de plusieurs milliers).