premature optimization is the root of all evil

[zwetan]

alors voila

un post comme ca arrive
http://www.insideria.com/2009/04/51-actionscript-30-and-flex-op.html

et une bonne 50aine de comment qui en gros disent "wouhou c'est
genial"

alors que le bon post c'est celui là
http://life.neophi.com/danielr/2009/05/be_wary_of_microbenchmarks_bar.html

et bien sur 0 comments

le 1er post commence par ca
"A homework assignment I was recently given for a Java programming
class involved a competition to see who could create the most
optimized implementation of an interface which was provided by the
instructor. It was a challenging and very fun assignment that I think
the whole class enjoyed. I didn’t win the competition but still came
out a winner because of my heightened interest in application
optimization and performance tuning that I gained."

qui en gros veut dire "je suis étudiant et j'apprends Java et j'ai pas
d'experience en programmation, et en plus
j'ai meme pas gagné le concours d'optimization"

et le 1er post continue
"While creating my concrete implementation for the homework assignment
I discovered a powerful profiling engine in NetBeans. The NetBeans
profiling engine helped me understand some of the memory usage and
consumption of each property, method call and object instantiation in
my program."

qui en gros veut dire "waouh j'ai decouvert le profiler de NetBeans et
j'ai beaucoup appris sur comment Java gere sa mémoire"

et puis
"I've been piecing together ActionScript optimization techniques and
practices from around the web for a couple years now."

qui en gros veut dire "alors j'ai cherché tous les blogs pour tous les
tricks d'optimiation depuis ces dernières années, meme ceux de AS2!!"

...

et tout le monde reponds en coeur "c'est genial", "à lire absoluement
pour tout developpeur qui se respecte"
et blah blah blah


et oui vous l'avez deviné le premier article m'énerve énormément
c'est limite presque un troll, ou comment plomber tout un bon tas de
dev AS3 (revenge d'un dev Java ?)
avec une liste d'optimization de merde

et non il ne melange pas du tout le MXML et l'AS3

bref, le seul conseil que je peux donenr c'est de lire le 2nd article
et de ne pas prendre comme "bible" ce gnere de liste d'optimization

zwetan

[Mem's]

Moi je serai plutot partagé :

D'un coté, si l'on veux optimiser une application c'est pas en faisant
tout ça que ça changera grand chose ... sauf dans les cas ou on
utilise énormément d'object (100k) ou des boucles à n'en plus finir
avec de nombreuses itérations.

En plus ce genre d'optimisation à prendre comme automatismes lorsque
l'on programme, c'est à ce retrouver avec du code inbuvable du style:
var half:uint = integer >>> 1;
au lieu de
var half:uint = integer / 2;

Mais d'un autre y a des choses qui tombes sous le sens avec le visible
= false/alpha = 0 qui permet d'éviter d'avoir un object qui reste
interactif alors qu'on ne le vois pas
Ou comme l'utilisation de uint à la place de Number pour des chiffres
entier non négatifs.
Ou d'autres comme le ENTER_FRAME à la place d'un Timer, enfin quand on
a des objects de la vue à rafraichir.
Dont certaines sont plus ou moins en rapport convention de codages :
http://opensource.adobe.com/wiki/display/flexsdk/Coding+Conventions

Cf. par exemple http://opensource.adobe.com/wiki/display/flexsdk/Coding+Conventions#CodingConventions-{{if}}statements
(la dernière)

J'avoue, ça m'a fait aussi penser que j'ai trop pris l'habitude de
minimiser l'utilisation de variables (un i pour plusieurs boucles)
array.length = 0;
au lieu de
array= [];
...

On 13 mai, 08:24, zwetan <zwe...@gmail.com> wrote:
> alors voila
>

> un post comme ca arrivehttp://www.insideria.com/2009/04/51-actionscript-30-and-flex-op.html

>
> et une bonne 50aine de comment qui en gros disent "wouhou c'est
> genial"
>

> alors que le bon post c'est celui làhttp://life.neophi.com/danielr/2009/05/be_wary_of_microbenchmarks_bar...

[dafunker]

La facon dont le premier mec presente ce qui l'a amene a vouloir en
savoir plus sur l'optimisation du code est ridicule, c'est vrai :)
A peu pret tout ce qui est dis ensuite est en revanche vrai.

Le 2eme poste est un peu extremiste je trouve, en gros il dit que les
gens perdent leur temps a optimiser et que pire, en cherchant
l'optimisation, ils pourraient rendre leur code moins performant sur
certaines machines/certains browsers.
Le 'MICRO BENCHMARKING' comme il est appele dans ce post est juste
remarquable dans une boucle qui itere enormement de fois. Juste par
exemple pour ces composants : carousel / coverflow / moteurs 3d /
moteurs de tweens, l'utilisation de certaines petites optimisation
peuvent faire gagner bien plus que 2 petites frame par secondes.

Faut pas tomber dans l'extreme, c'est a dire benchmarker son 'AS3 RSS
Reader' ou bien ne rien benchmarker du tout.

'Real world performance problems are almost always going to be
inefficient algorithms long before your Array initialization technique
starts taking up the majority of your time'
David R a raison sur ce point, c'est pas les petits tweaks qu'il
faille chercher en premier mais bien l'amelioration de l'algorithme
utilise. Apres, de la a dire que initialiser les Array avec [] plutot
qu'avec new Array() demande plus de temps de developpement ... :)
C'est pour ca que je le trouve un peu extremiste, il exclu totalement
l'optimisation via 'tweaks' alors que c'est tout de meme necessaire
dans certains cas.

On 13 mai, 14:29, "Mem's" <m.tool...@gmail.com> wrote:
> Moi je serai plutot partagé :
>
> D'un coté, si l'on veux optimiser une application c'est pas en faisant
> tout ça que ça changera grand chose ... sauf dans les cas ou on
> utilise énormément d'object (100k) ou des boucles à n'en plus finir
> avec de nombreuses itérations.
>
> En plus ce genre d'optimisation à prendre comme automatismes lorsque
> l'on programme, c'est à ce retrouver avec du code inbuvable du style:
> var half:uint = integer >>> 1;
> au lieu de
> var half:uint = integer / 2;
>
> Mais d'un autre y a des choses qui tombes sous le sens avec le visible
> = false/alpha = 0 qui permet d'éviter d'avoir un object qui reste
> interactif alors qu'on ne le vois pas
> Ou comme l'utilisation de uint à la place de Number pour des chiffres
> entier non négatifs.
> Ou d'autres comme le ENTER_FRAME à la place d'un Timer, enfin quand on
> a des objects de la vue à rafraichir.
> Dont certaines sont plus ou moins en rapport convention de codages :http://opensource.adobe.com/wiki/display/flexsdk/Coding+Conventions
>

> Cf. par exemplehttp://opensource.adobe.com/wiki/display/flexsdk/Coding+Conventions#C...{{if}}statements

[ekameleon]

Hello :)

Pour moi tout est question d'expérience ... plus on code plus on s'habitue à utiliser certaines choses... et certaines choses sont bonnes et d'autres non :)

Donc oui il ne faut surtout pas se prendre la tête pendant que l'on code mais si on a l'habitude à force d'expérience d'optimiser son code.. bah autant le faire sans se prendre la tête :)

EKA+ :)

[zwetan]

ce qui me gene le plus, c'est le coté "liste de trick"

aussi le 2nd post a pas mal raison sur le fait que le gars du 1er
post,
ne justifie pas ces tricks en les testant (et donc en donnant la
preuve de l'optimization)

perso j'ai rien contre l'optimization mais j'écris rarement du code
qui ne doit pas etre maintenu dans le temps, et quand il y a ce
facteur en compte

meme si "integer >>> 1" est qlqs micro secondes plus rapide c'est qd
meme mieux
de lire et maintenir du code écris avec "integer * 2"

là où aussi le 2nd post a raison c'est sur les optimizations que fait
le compilo,
ce genre d'optimization est bien plus efficace que des tricks

par contre, comme le but du 1er post est de pondre une bonne grosse
merdasse de tricks,
on se retrouve avec un fourre-tout

utliser "visible = false" au lieu de "alpha = 0", je ne vois pas ca
comme un trick
c'est juste connaitre comment le flash payer fonctionne, bref ca reste
lisible et controlable

mais pour finir je dis que Knuth a tres bien formulé le probleme
"premature optimization is the root of all evil"

il dit pas que l'optimization est evil, mais que l'optimization
premature est evil

cad qlqn qui prends la liste de trick et l'applique a son code dès le
début et partout,
je trouve ca stupide, car c'est essayer de faire de l'optimization
sans meme savoir si on en
a besoin ou pas

si du code doit etre optimisé, c'est à la fin, pas au début
et seulement si il y a besoin d'optimiser

et si on décide d'optimiser qlqch, ca doit etre testé,
pas juste appliquer des tricks ici ou là, mais vraiment testé le
"avant" et "apres"
et mesurer le gain de vitesse ou autre, cad savoir ce qu'on fait

la performance ca vient pas d'une liste de tricks, ca vient de tests
comme ici par ex: http://tamarin-builds.mozilla.org/performance/
(le server est donw pour le moment mais bon ...)
bref, ca se mesure

zwetan