Tagged: performance

Android : quelles sont les applis les plus nocives pour les performances de votre smartphone ?

L’éditeur de solutions de sécurité AVG a analysé des milliers de smartphones sous Android et publié un impressionnant rapport qui révèle les applications les plus gourmandes en énergie, stockage et données échangées.

Source : Android : quelles sont les applis les plus nocives pour les performances de votre smartphone ?

Ca fait partie des trucs qui m’agacent. C’est bien de vouloir proposer des applis pour faire du blé mais ce serait mieux de tenir compte du confort de l’utilisateur. Enfin c’est sur, ca rapporte peu au final donc on s’en fou. Comme toujours.

More

LinuxFr.org

Avant de commencer et pour ceux qui ne connaissent pas encore Glances, voici une définition de l’objectif de ce logiciel: « Glances est un outil permettant d’identifier le plus simplement possible les problèmes de performance d’une machine ».

via LinuxFr.org.

Tiens je me mets ca de côté. L’outil commence à avoir l’air pas mal abouti et je pense qu’à un moment ou un autre on a toujours besoin de choses comme ça dans sa caisse a outil :p

More

Snippet #24 ~ PHP: Allégez vos classes avec des get/set automatiques | IdleBlog – Liens en vrac de sebsauvage => OUPAH

Astuce php pour éviter d’avoir à se palucher plein de getters/setters pour des classes de stockage.

via Snippet #24 ~ PHP: Allégez vos classes avec des get/set automatiques | IdleBlog – Liens en vrac de sebsauvage.

Ou alors revenir à la raison dans certains cas et ne pas appliquer les concepts de la POO façon recette de cuisine vaseuse sans prendre de recul. Par exemple pour des DTO ça ne sert strictement à rien selon moi de persister à utiliser des getters / setters. Mais alors à rien du tout ! Pire c’est contre productif à tous les niveaux.

Les DTO sont des objets destinés uniquement à stocker de la donnée. Aucune intelligence dedans. Pire, quand on fait du getter / setter dans un DTO on apporte même pas d’API et de stabilité dans les évolutions puisque les getters / setters sont nommés en fonction des données associées et donc le nom de ces méthodes est largement aussi peu stable que les attributs associés… Sans compter les cas ou les valeurs derrière ne sont même pas protégées puisqu’il y a des passages par référence des objets (cas pas assez souvent abordé en java selon moi).

Pire encore en terme de performance ! Utiliser du getter / setter à tarbasse dans certains cas (ici le DTO) est juste une immondice de performance. Ne pas oublier que quand vous concevez une méthode et l’utilisez l’interpréteur / la machine effectue un branchement / débranchement de l’exécution pour faire l’appel (sauf dans certains cas ou des optimisations sont possibles par le compilateur). Or c’est un processus qui prend du temps par rapport a une exécution séquentielle… Imaginez ça multiplié par le nombre de champs et d’enregistrements…

Et das certains cas (dans ce lien) on se retrouve a écrire des systèmes dégeu de génération dynamique des getters / setters, ce qui est largement aussi moche et prend du temps tout ça pour éviter une flemme d’écriture de code.

Bref, ne pas appliquer les recettes de cuisine brutos et prendre du recul est salvateur. Par exemple, dans le cas d’une DTO, arrêtez de continuer avec vos attributs privés et des getters / setters de merde. Passez simplement vos attributs en public ! Vous gagnez en temps d’exécution (accès mémoire only), vous gagnez en lisibilité et maintenance du code (attributs only) et vous ne perdez rien au passage…

Si vous ne me croyez pas je vous cite un bout de doc officielle de la javadoc (mais je pense que c’est applicable d’une manière générale).

http://www.oracle.com/technetwork/java/transferobject-139757.html

Typically, the members in the Transfer Object are defined as public, thus eliminating the need for get and set methods.

Bon après j’ai longtemps fait des getters / setters sur des DTO avant de penser ainsi.

Attention je parle bien de tout cela dans le cadre des objets de données purs, ne pas mélanger mes propos avec des classes définissant une API ou une intelligence métier.

More