https://web.archive.org/web/20121118053638/https://developer.android.com/training/articles/perf-tips.html

La page à presque pas changée depuis 2012, il y a juste la partie "avoid internal Getter/setter" qui a été supprimée, j'ai pas vérifié mais je suis presque sur d'avoir vu cette partie plus tôt cette année, donc ça a été changé il y a pas longtemps mais les autres parties ont pas été modifiée, je sais pas trop ce qu'il faut en penser du coup

"There are two basic rules for writing efficient code:

Don't do work that you don't need to do.
Don't allocate memory if you can avoid it."

ça me semble logique

Après pour contribuer à la discussion sur l'optimisation et la POO (en dehors de mon cas trivial et des cas de microoptimisation inutiles), j'ai lu ce commentaire récent (sous forme de thread de message twitter, ultra pratique) qui explique pas mal certaines contraintes d'optimisations:
https://twitter.com/etoddodd_/status/936422488787038208

Mais on reste dans les mêmes considérations, si t'en es au point d'optimiser des getters, t'as mal pensé ton application à la base.

(sous forme de thread de message twitter, ultra pratique)

C'est ironique ?

Mais on reste dans les mêmes considérations, si t'en es au point d'optimiser des getters, t'as mal pensé ton application à la base.
Surtout qu'il y a tellement de profiler puissant maintenant que c'est facile de savoir où optimisation il y a nécessité

Le 04 décembre 2017 à 17:49:00 lokilok a écrit :

(sous forme de thread de message twitter, ultra pratique)

C'est ironique ?

Très ironique.

Le 04 décembre 2017 à 18:05:11 [-Shana-] a écrit :
Mais on reste dans les mêmes considérations, si t'en es au point d'optimiser des getters, t'as mal pensé ton application à la base.
Surtout qu'il y a tellement de profiler puissant maintenant que c'est facile de savoir où optimisation il y a nécessité

C'est sûr. Et dans le doute le dicton prévaut: "premature optimization is the root of all evil". (Même si ce dicton peut-être utilisé un peu n'importe comment )

Je m'étais déjà posé la question des getters / setters pour Android, parce que la doc officielle disait de faire attention à ça. Je m'étais dit que peut-être que pour un jeu Android qui est susceptible d'en appeler énormément à la seconde ça peut être bénéfique de les inliner. (je sais pas si ça a été le cas pour la version desktop par contre, je pense pas mais j'en sais rien)

Mais j'avais vu ce post de 2011 qui dit que depuis ils avaient bossé sur la jvm d'android et que ça inlinait déjà tout seul les getters et setters parfois : https://stackoverflow.com/questions/4912695/what-optimizations-can-i-expect-from-dalvik-and-the-android-toolchain/4930538#4930538

Et quoiqu'il en soit, on peut toujours passer son code à la moulinette progard (c'était recommandé à l'époque, maitnenant je sais pas) pour inliner les getters et setters automatiquement donc pas besoin de faire attention à ça quoi qu'il arrive sauf si progard te pose problème pour une raison x ou y

Surtout qu'avant Android ça utilisait Dalvik comme machine virtuelle, depuis ça a été remplacé par Art et tu as un compilateur AOT quand t'installe les applications, et ça m'étonnerait pas que ça s'occupe de ce genre d'optimisation en amont.

Donc depuis tout ce temps je suppose que ça ne joue plus ou presque plus, mais j'en sais rien je dis peut être des bêtises

Et pour les phones qui sont vieux au point de même pas avoir de JIT, à mon avis ils sont habitués aux soucis de perf'

Et pour les phones qui sont vieux au point de même pas avoir de JIT, à mon avis ils sont habitués aux soucis de perf'

Gaffe à ce que tu dis sur les téléphones low cost
C'est un marché potentiel

Attention je parle pas des téléphones low cost mais de ceux qui ont une version d'android qui date genre de plus de 7 ans

Je sais même pas si l'appli Android Market marche encore bien vu depuis, pour ceux qui ont pas la nouvelle appli Google Play

Le 04 décembre 2017 à 21:54:07 Arkwolf a écrit :
Attention je parle pas des téléphones low cost mais de ceux qui ont une version d'android qui date genre de plus de 7 ans

Je sais même pas si l'appli Android Market marche encore bien vu depuis, pour ceux qui ont pas la nouvelle appli Google Play

A l'époque je crois que le google store existait même pas hein

Génial... voilà que maintenant des gens volent les maps des autres et les font passer pour leurs.
https://gamejolt.com/games/SlendermansPastDemoV1/299195

Le 04 décembre 2017 à 22:59:19 TERMlNAT0R a écrit :
Génial... voilà que maintenant des gens volent les maps des autres et les font passer pour leurs.
https://gamejolt.com/games/SlendermansPastDemoV1/299195

Comme ça me ferait chier d'être pris en flag de vol de contenue
Heureusement je prends que de l'open source au besoin

Après, c'est une map que tout le monde peut modifier car elle n'est pas compilée en jeu stand-alone. Donc peut-être qu'elle est ré-utilisable, mais l'auteur du pack (et donc de la map) n'a jamais indiqué qu'on pouvait le faire.

A l'époque je crois que le google store existait même pas hein

Ouais c'est ce que je dis, ça s'appelait android market avant et je sais même pas ce que ça donne aujourd'hui du coup

Chaud le voleur de maps je me demande s'il va répondre

Le 05 décembre 2017 à 13:52:35 Arkwolf a écrit :

A l'époque je crois que le google store existait même pas hein

Ouais c'est ce que je dis, ça s'appelait android market avant et je sais même pas ce que ça donne aujourd'hui du coup

Chaud le voleur de maps je me demande s'il va répondre

Ouais me semble
D'ailleurs j'ai fais montrer le code de ta boite (de manière anonyme, np ) a mon professeur qui taff à l'armée et à quelques potes, ils ont bien rigolé !

"Après, c'est une map que tout le monde peut modifier car elle n'est pas compilée en jeu stand-alone. Donc peut-être qu'elle est ré-utilisable, mais l'auteur du pack (et donc de la map) n'a jamais indiqué qu'on pouvait le faire. "
Puis le mec n'a pas non plus crédité l'auteur dans tous les cas, donc ça reste pas cool !

de manière anonyme

T'avais peur que ton prof envoie les chars d'assaut pour faire cesser cette hérésie ?

Le 05 décembre 2017 à 14:26:55 whiteapplex a écrit :

de manière anonyme

T'avais peur que ton prof envoie les chars d'assaut pour faire cesser cette hérésie ?

Plus par respect pour l'entreprise de ArK et lui même

Le 03 décembre 2017 à 22:08:36 whiteapplex a écrit :
Quand des gens me disent de sauvegarder des "get" pour optimiser un programme
ET C'EST DU JAVA BORDEL ! DU JAVA ! OPTIMISER DU JAVA ! Pourquoi pas optimiser du python tant qu'on y est
C'est eux qui devraient aller à 42, mais ils vont sortir bac+5 hein
Bon dites moi honnêtement si je me trompe, je veux savoir, si sauvegarder un "get" c'est vraiment une bonne pratique de programmation en Java. Est-ce qu'on en est là ? Au point où il vaut mieux un

class A { B b; C c; void init(){b=c.getB()} ; void foo(){ b.foo(); } }

à un

class A { C c; void foo { c.getB().foo(); } }

C'est pas des choses qui seront optimisées avec 99% de chance en compilation OU qui valent pas le coup d'être optimisée (on parle d'un programme avec des milliers de lignes de codes et une interface graphique) ?

En general le compilateur ne peut pas optimiser ce genre de chose. Parceque le compilatur ne peut pas forcement savoir si C.b est sucesceptible de changer ou pas entre l'appel a A.init et l'appel a A.foo. Du coup il ne peut pas faire cette optimization. Est ce que l'optimisation est utile? Ca depend de l'implementation de C.getB(); Mais en general, ca sauve un dereferencement de pointeur. Donc potentiellement un lookup en TLB et un cache miss.

Si les structures de donnees de ton application sont tres creuse, tu peux rapidement perdre de la perf, surtout quand tu as des architectures immonde ou C.getB() appelle D.getB() qui appelle E.getB() etc. ce qui est une structure relativement classique en java.

Le 04 décembre 2017 à 17:38:26 whiteapplex a écrit :
Après pour contribuer à la discussion sur l'optimisation et la POO (en dehors de mon cas trivial et des cas de microoptimisation inutiles), j'ai lu ce commentaire récent (sous forme de thread de message twitter, ultra pratique) qui explique pas mal certaines contraintes d'optimisations:
https://twitter.com/etodd_/status/936422488787038208

Mais on reste dans les mêmes considérations, si t'en es au point d'optimiser des getters, t'as mal pensé ton application à la base.

Note que le message du mec suppose que le programme ne tiens pas en compte de la memoie.
le POO c'est un modele d'access au donne, pas un modele de representation des donnees.
Tu peux tres bien structurer tes donnees compacte en memoire et sans allocation dynamique, mais avoir une couche d'abstraction objet qui presente des absractions simple a comprendre et a utiliser.

Le 05 décembre 2017 à 13:54:32 [-Shana-] a écrit :

Le 05 décembre 2017 à 13:52:35 Arkwolf a écrit :

D'ailleurs j'ai fais montrer le code de ta boite (de manière anonyme, np ) a mon professeur qui taff à l'armée et à quelques potes, ils ont bien rigolé !

Le compteur en JS ou l'entité PHP ? Le compteur il est légendaire il a fait le tour du monde un peu (lien pour ceux qui avaient pas vu : https://gist.github.com/Arkounay/eb9027c49a1d44ca9a100f4577f7bf31 )

Le pire c'est qu'il y a une nouvelle personne qui fait la même chose, le cancer se répand, je laisse tomber perso je vais chercher un autre taf pour 2018 sinon je pourrais pas progresser et je finirais blasé avec des gens comme ça

Plus par respect pour l'entreprise de ArK et lui même

De toute façon avec tous les projets mal fait / buggés qui sortent t'inquiète pas la réputation se fait d'elle même sans voir le code

Merci pour les explications Godrik