octobre
2012
Un article de bouye
Richard Bair
Jasper Potts est dans l’audience.
Écrivez du code clean puis ensuite profilez !
Certaines chose seront optimisées dans JavaFX 8
> performances
> règles pour bonnes performances
1) En faire le moins possible : moins de nœuds dans le SceneGraph.
2) Pour les systèmes embarqués, il faudra passer du temps à optimiser et les optimisations peuvent se trouver là où vous vous y attendez le moins.
– Chaque ligne de code compte !
– Trop d’appel de méthode ralenti le code !
– déclarer des membres finals dans le code de la méthode aide.
3) les limites :
– le fillrate de la carte (100% certain)
– le geometry rate de la carte (peu probable)
– trop de temps dans la gestion des CSS (ça peut arriver)
– trop de temps passé à faire du layout (possible)
– les IO systèmes (probable)m
> astuces
1) Limiter les trucs à faire
Dessiner uniquement ce qui a changé.
Utilisation des dirty regions -> fait automatiquement par le SceneGraph. Attention cependant lors de l’utilisation de Canvas, il faut les gérer manuellement.
Limitation l’utilisation des effets.
Limitation l’utilisation des zones non-rectangulaires ou non-alignées sur les axes. Pareil pour le clipping avec des zones non-rectangulaires ou non-alignées sur les axes.
Réduire les superposition de peinture (trop de couches dessinées inutilement)
Utiliser des skins bitmap !!!! Ça améliore énormément les perfs !
Cache automatique des textures d’une région (JavaFX 8)
Consolidation des remplissages des fonds
Réduire le nombre de nœuds QUI SE CHEVAUCHENT !!!!!
Occlusion culling (fait par l’API) -> il est possible, via CSS d’indiquer quelles région d’une image est opaque pour éviter un calcul inutile par l’API.
parsing des fichiers CSS
Quand l’id d’un noeud change
Quand un nœud a une règle qui dépend d’un nœud parent .parent .child ou .parent:hover .child
Éviter de trop utilise setStyle() : parsing + computing supplémentaire.
Mieux vaut utiliser l’inclusion immédiate .parent > .child
Éviter de modifier la structure du SceneGraph trop souvent.
Utiliser toFront() et toBack() plutôt que retirer puis ajouter de la liste des children
Utiliser les collections FX pour plus d’efficacité mas les utiliser intelligemment.
Utiliser setAll() plutot que clear() + addAll(). Éviter trop d’appels à add().
Utiliser FXCollections.sort() au lieu de Collections.sort() pour minimiser les events.
Réutiliser les nœuds : optimisation mémoire + CSS
Ne pas hésiter à utiliser ListView pour la virtualisation
Faire des layout manuels : hériter de Region -> surcharger les méthodes de calcul des tailles préférées. Implémenter layoutChildren()
Penser à indiquer le contentBias pour donner une indication de l’orientation. Un contentBias à null (largeur et hauteur indépendantes l’une de l’autre) est plus rapide. !!! Il y a un bug actuellement dans l’API pour les layouts par défaut
2) connaitre les limites du hardware qu’on utilise.
Écrire pour Raspberry Pi est différent d’écrire pour desktop même si on écrit en Java !!!
3) Si rien ne change -> CACHE !!! Pas toujours possible suivant le hardware cependant !
Penser à utiliser les cache hint.
4) Dans JavaFX 8, utiliser -Djavafx-pulseLogger=true pour diagnostiquer ce qui se passe à chaque pulse
2 Commentaires + Ajouter un commentaire
Commentaires récents
- dans Back from the future…
- dans Back from the future…
- dans Static linking = does not Compute
- dans Paquetage x 2
- dans Why you little…
Bon boulot c’est très intéressant d’avoir ce résumé.
Faut penser a aller voir la présentation (slides + audio) sur le site de la JavaOne pour avoir toutes les informations (https://oracleus.activeevents.com/connect/sessionDetail.ww?SESSION_ID=6784 pour cette session).