Catégorie: Perfs

Je viens de tomber sur un billet de Remi Forax, qui signale l'activation par défaut de l'escape analysis dans Java 7.

Sous ce nom étrange se cache une optimisation de la JVM lui permettant de mieux utiliser la pile (stack) pour stocker les variables locales, ce qui permet normalement de simplifier les allocations/libérations d'objets tout en améliorant les performances...

Je n'ai pas encore pu tester cela, mais le billet de Remi Forax indique des performances 3 fois plus importante lors de la création d'un objet en boucle.

Mais comment utiliser l'allocation sur la pile ?

» Lire la suite!

Je viens de tomber sur un article assez intéressant concernant les problèmes liés à la mémoire en Java, et plus particulièrement dans les applications serveurs (là où elles se font le plus ressentir).

L'auteur les répertorie en quatre grandes catégories :

• Les memory leaks qui surviennent lorsqu'on conserve inutilement des références vers des objets que l'on n'utilise plus (comme lorsqu'on abuse du scope "session" par exemple).
• L'utilisation abusive de mémoire, causée par des implémentations qui chargent un grand nombre de données simplement pour les réutiliser plus facilement par la suite, au risque de conserver en mémoire un grand nombre de données peu usité...
• Des créations d'objet inefficaces, généralement causées par des algorithmes inadaptés aux fortes charges, et qui donnent beaucoup de travail au GC.
• Enfin une configuration inefficace du GC, voir une absence de configuration, alors qu'un bon paramétrage en fonction des besoins permettrait un gain de performance de 25%.

Bonne lecture : Java Memory Problems

Rien n'est complètement inutile, malgré des apparences qui pourraient laisser présager le contraire...

L'API Java propose un constructeur de copie String(String) pour la classe String. Pour rappel le constructeur de copie est une notion très importante en C++ où des copies d'objets sont obligatoires afin de gérer proprement la mémoire (lorsqu'on n'utilise pas de GC), sinon on ne saurait plus si l'objet est libérable ou pas. A l'inverse, en Java ce concept est rarement utilisé puisque le GC couplé à la notion d'immuabilité des classes permet de partager des instances entre plusieurs classes sans que cela ne cause de problème. Cela permet d'éviter d'avoir à faire de multiples copies de protection...

La classe String étant immuable, la création de copie de protection est donc inutile. De ce fait pendant longtemps j'ai pensé que la présence de ce constructeur de copie String(String) était une bizarrerie de l'API, que l'on se traine pour des raisons de compatibilité ascendante.

» Lire la suite!

La dernière version d'eclise, surnommé Ganymede, est sorti il y a à peine quelques jours, et apporte son lot de nouveautés et d'amélioration.

A première vue cette release semble être une très bonne cuvée, mais en consultant la liste des nouveautés des outils de développement Java, je suis tombé sur une nouvelle fonctionnalité qui m'a quelque peu irrité : un "quick assist" sur la concaténation de chaine de caractère...

» Lire la suite!

Cette semaine aura été consacré à la classe SwingWorker de Java 6 : vous n'aurez sans doute pas manqué l'article de Romain Vimont concernant des interfaces graphiques plus performantes avec SwingWorker, mais peut-être que vous êtes passé à coté d'un sujet sur le forum qui a fini en mini-débat...

Pour info/rappel, SwingWorker permet d'exécuter un traitement dans une tâche de fond et ainsi de laisser l'EDT faire son travail, c'est à dire de gérer l'affichage des composants et les évènements graphiques.

» Lire la suite!

L'API Java est vraiment énorme. Elle offre un grand nombre d'outils et de possibilités qui, bien souvent, ne sont pas utilisées tout simplement parce qu'elles sont méconnues...

Cela faisait quelques temps que je voulais m'intéresser plus particulièrement aux diverses références de Java, et le récent article sur les références faibles sous .NET m'avait donné l'eau à la bouche... Et voilà qu'un article en anglais les décrit avec des exemples concrets : Understanding Weak References.

Je me suis donc jeter dedans et je vais essayer de vous présenter cela.

» Lire la suite!

Dans une discussion récente sur le forum Java concernant la génération d'un exécutable, j'ai indiqué qu'un code natif n'étais pas forcément plus rapide que du bytecode, et que cela pouvait même être l'inverse puisque les JVM actuelles utilisent un compilateur JIT.

Comment cela pourrait-il être possible ?

Lorsqu'on compile un code natif, les compilateurs n'activent pas toutes les optimisations possibles afin que le programme puisse s'exécuter sur des machines ne disposant pas forcément du même type de matériel (et particulièrement le CPU).

A l'inverse, le bytecode Java est compilé dynamiquement à l'exécution par le compilateur JIT. Ce dernier peut donc prendre en compte les spécificités de la machine. Le gain de performance peut être très important...

Je vais donc essayer de faire quelques tests afin de comparer les temps d'exécution...

» Lire la suite!

On entends parfois dire que l'utilisation de bloc try/catch pouvait être pénalisant en terme de performance dans une application. Si bien que certain préfèrent retourner un code d'erreur plutôt que de lever une Exception...

J'ai voulu déterminer quel était la part de vérité et de d'estimer si cela est vraiment pénalisant dans une application...

J'ai donc comparé les performances d'une méthode dont la gestion des erreurs est basée sur le principe des exceptions, avec une autre qui se contente de retourner un code d'erreur.

» Lire la suite!