Discussion :

[Invité]

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

[Alkhan]

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.

[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++

[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.

[Invité]

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).

[tchize_]

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.

[Invité]

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".

[adiGuba]

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++

[Invité]

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