salut
 
simplement pour savoir votre opinion sur l'optimisation de boucles for
 
faut t'il mieux faire

 
ou
 

 
 
 
ou est identique niveau execution (ce que je pense)

t'utilise juste un variable en plus dans le deuxieme cas donc bon je pense le premier mieux

une variable, ca ne coute absolument rien, par contre dans le premier cas tu peux te manger un appel de fonction a chaque iteration

le compilo ou la JVM doivent surement l'optimiser d'eux meme...

ben je connais les risques , mais la question est ce que la JVM optimise le truc en ne faisant q'une fois l'appel a toto.longeur() en deduisant d'elle meme que la longeur n'est pas modifie dans la boucle  
 
si mes souvenirs sont bon en C/C++ cette optimisation est faite

 
fo voir. Dans un cas simple comme ca la JVM doit inliner ca et ca regle le pb. Mais tu peux imaginer des cas plus compliqué avec des effets de bords et ce genre de connerie empechant une fine optimisation (meme si utiliser une fonction avec effet de bords dans une limite de boucle, c'est tres mail)

(le compilo C++ va surtout te passer un coup d'inlining)

donc en conclusion je devrais lever l'inconnu en passant par une variable intermediaire ...

en conclusion, faudrait demander à nraynaud...lui saura...

 
ou faire un bench vite fait
Cela dit c'st pas la peine de saloper ton code dans tous les cas, y'a fort a parier que ca changera rien (sauf si la fonction appelée fait vraiment tout un tas de bordel)

Honnétement j'espére bien que c'est deux boucles sont différentes : si la taille de mon tableau change dans le bloc du for, je suis bien "fait" si sa taille est sauvegardé à la rentrée dans la boucle.
Bref je vote que la premiére proposition va plus vite.

sur un tableau l'optimisation est peut être faite ... c'est pas dur de vérifier si le tableau a des chances d'être modifié (déclaration locale ou privée + non modification dans la boucle).
Par contre sur des ArrayList ou autre, ca me parait pas possible ...
 
Dans tous les cas c'est facile à vérifier : un petit coup de décompilation et hop !
 

 

Faudrait voir a pas dire n'importe quoi hein ?

si t'as une précision à ajouter donne là sinon dehors

... c'est pas ton (dé)compilo qui va te dire si la vm fait oui ou non de l'inlining sur ta boucle...

 
attends, je fais caca dans ma culotte de trouille....voila, c'est fait
 
Alors mon petit benou, un jour que tu auras 5s de libre entre deux menaces de sanction, tu decompileras du code compilé par javac, hein ? et tu verras, sous tes yeux ébahis que javac optimise rien (*rien*, RIEN), meme pas a = 3 + 2; Alors on va pas lui demander de faire de l'inlining ou je sais pas quoi. Je sais pas si tu as lu ce topic, mais on parle a chaque d'optimisation faite par la JVM, pas par un quelconque compilo java.
Donc ta décompilation, elle va servir a rien

 
+1 pour cette solution mais il faut être absoluement sur que la longueur de toto est constante tout le long de l'exécution de la boucle.

D'après le lien http://www.protomatter.com/nate/java-optimization/, le mieux serait un truc du genre
 

Pas pour rendre le code lisible, en tout cas.
 
Hors de question.

ce site propose des optimisations douteuses...le coup d'initialiser une array en jouant sur un indexOutOfBounds c très très crade...
 
je suis pas sur que le gain de perfs vaille la peine de pourrir son code à ce point...pis les exemples sont donnés en JDK 1.1 ...depuis, la JVM a du vachement murir...si une optimisation est aussi évidente à écrire que ca, je vois pas  pkoi la JVM le mettrait pas en oeuvre, vu que c super facilement automatisable, l'optimisation comme la vérification de ses conditions d'application...

sans déconner le résultat du hash d'un String est pas mis en cache ?

 
personnelement je n'accorde que peu de credit a ce qu'il y écrit, la plupart du temps c'est du branlottage (genre il te cite knuth au debut pour ensuite venir pinailler sur des index de boucle) ou sinon on sent le truc completement pas mis a jour (le paté sur les vars locales a la fin, par ex)

taz: bah si..

d'accord, mais d'un autre côté, si c'était le cas, tu serais pas entièrement surpris ?
 
edit : ah quand même. Note que ces les dites techniques de sioux qui sont utilisées. L'algo est pas terrible lui (FNV pawa)

 
ah bin finalement il a peu etre raison sur le paté "variable locale", a voir comment la fonction est codée

TU parles d'optimisation faite par la JVM ...  
et chez moi le 3+2 il est transformé en 5  
 
et tu sais, t'es pas obligé de mon tomber dessus à chacun de mes posts ...

<quake version="3>Impressive !</quake>
 
Cela dit des fois, je parle pour Java comme pour C#, c'est vrai que les compilos foutent vraiment rien et se repose sur le "le JIT va se démerder (et bien pourrir le cache entre autres)"

regarde blabla

 
Ah ?
 

 
vivi y'a que moi qui parle de la JVM
et javac est bien connu pour optimiser comme un sagouin
 
 
 

 
bon, allez, au pire je t'accorde le constant folding (en entier), mais c'est tout
 

dessous des strings

j'en fais des cauchemards de ton topic

ce qui est chiant c'est qu'il ja d'abord faire une mesure de perf avant de tenter d'inliner ou de compiler, donc sur peu d'itérations, ça va réellement faire une tonne d'appels (en interprété), puis ça va inliner puis compiler.

Il est marrant ce topic
 
Je comprend pas encore trop l'interet de chipoter pour une optimisation si minime. Si ce problème devait finir par être critique, c'est que la modelisation n'est pas bonne. Ou qu'il faut changer de langage et faire de l'assembleur .

L'optimisation est sans intérêt, mais la compréhension de la machinerie sous-jacente est hautement intéressante

Bonjour,
 
En Java, contrairement à C++, le coût d'appel d'une fonction doit être considéré comme zéro (je parle bien de l'appel pas de ce que fait la fonction). En conséquence, si toto.longueur() se contente de retourner une valeur, la première solution est la plus naturelle. Evidemment, si toto.longueur() faisait un calcul long, il serait plus intéressant de stocker le résultat (deuxième cas).
 
Par ailleurs, c'est une question largement débattue de savoir comment optimiser la déclaration d'une boucle mais...:
 
- Les développeurs du compilateur ont sûrement dû y penser eux aussi
- Le gain éventuel est souvent négligeable par rapport au temps d'éxécution de chaque itération.
 
Très cordialement,