pour l'optimisation de boucle
List<String> flowers = new ArrayList<String>();
Ma boucle for ressemble actuellement à ceci ...
for (int i = 0; i < flowers.size(); i++) {
...
}
OU devrais-je changer cela pour ressembler au code donné ci-dessous
int size = flowers.size();
for (int i = 0; i < size; i++) {
...
}
Ce qui est plus performant (en supposant que j'ai un large éventail de fleurs), je suppose que ce devrait être le dernier.
Il vaut mieux utiliser pour chaque boucle [plus lisible]
for (Flower flower :flowers){
//...
}
J'ai vidé des instructions en utilisant javap pour le code suivant:
public void forLoop1() {
List<String> lst = new ArrayList<String>();
for (int i = 0; i < lst.size(); i++) {
System.out.println("hi");
}
}
public void forLoop2() {
List<String> lst = new ArrayList<String>();
int size = lst.size();
for (int i = 0; i < size; i++) {
System.out.println("hi");
}
}
public void forLoop1();
Code:
0: new #2; //class Java/util/ArrayList
3: dup
4: invokespecial #3; //Method Java/util/ArrayList."<init>":()V
7: astore_1
8: iconst_0
9: istore_2
10: iload_2
11: aload_1
12: invokeinterface #4, 1; //InterfaceMethod Java/util/List.size:()I
17: if_icmpge 34
20: getstatic #5; //Field Java/lang/System.out:Ljava/io/PrintStream;
23: ldc #6; //String hi
25: invokevirtual #7; //Method Java/io/PrintStream.println:(Ljava/lang/Str
ing;)V
28: iinc 2, 1
31: goto 10
34: return
public void forLoop2();
Code:
0: new #2; //class Java/util/ArrayList
3: dup
4: invokespecial #3; //Method Java/util/ArrayList."<init>":()V
7: astore_1
8: aload_1
9: invokeinterface #4, 1; //InterfaceMethod Java/util/List.size:()I
14: istore_2
15: iconst_0
16: istore_3
17: iload_3
18: iload_2
19: if_icmpge 36
22: getstatic #5; //Field Java/lang/System.out:Ljava/io/PrintStream;
25: ldc #6; //String hi
27: invokevirtual #7; //Method Java/io/PrintStream.println:(Ljava/lang/Str
ing;)V
30: iinc 3, 1
33: goto 17
36: return
Ça n'optimise pas pour moi.
Java version "1.6.0_22" Java (TM) SE Runtime Environment (build 1.6.0_22-b04) Java HotSpot (TM) Client VM (build 17.1) -b03, mode mixte, partage)
Donc, si vous avez besoin de choisir parmi les deux mentionnés, optez pour la seconde, mais personnellement, je choisirais for-each.
pour chaque performance
De l'article 46 dans Java efficace par Joshua Bloch:
La boucle for-each, introduite dans la version 1.5, supprime l'encombrement et la possibilité d'erreur en masquant complètement l'itérateur ou la variable d'index. L'idiome résultant s'applique également aux collections et aux tableaux:
// The preferred idiom for iterating over collections and arrays for (Element e : elements) { doSomething(e); }Lorsque vous voyez le signe deux-points (:), lisez-le comme "in". Ainsi, la boucle ci-dessus se lit comme "pour chaque élément e dans les éléments". Notez qu'il n'y a pas de pénalité de performance pour l'utilisation de la boucle for-each, même pour les tableaux . En fait, il peut offrir un léger avantage de performance par rapport à une boucle for ordinaire dans certaines circonstances, car il ne calcule la limite de l'index du tableau qu'une seule fois. Bien que vous puissiez le faire à la main (point 45), les programmeurs ne le font pas toujours.
Voir également
Désolé de le dire, mais la réponse de @ Jigar est incorrecte. Ceci est la bonne réponse. (tldr; n'utilisez pas for : each).
import Java.util.ArrayList;
import Java.util.List;
public class LoopTest {
public static void main(String s[]) {
long start, end;
List<Integer> a = new ArrayList<Integer>();
for (int i = 0; i < 2500000; i++) {
a.add(i);
}
///// TESTING FOR : EACH LOOP
start = System.currentTimeMillis();
for (Integer j : a) {
int x = j + 3;
}
end = System.currentTimeMillis();
System.out.println(end - start
+ " milli seconds for [ Integer j : a ] ");
////// TESTING DEFAULT LOOP
start = System.currentTimeMillis();
for (int i = 0; i < a.size(); i++) {
int x = a.get(i) + 3;
}
end = System.currentTimeMillis();
System.out.println(end - start
+ " milli seconds for [ int i = 0; i < a.length; i++ ] ");
////// TESTING SLIGHTLY OPTIMIZED LOOP
start = System.currentTimeMillis();
int size = a.size();
for (int i = 0; i < size; i++) {
int x = a.get(i) + 3;
}
end = System.currentTimeMillis();
System.out.println(end - start
+ " milli seconds for [ int i = 0; i < size; i++ ] ");
//// TESTING MORE OPTIMIZED LOOP
start = System.currentTimeMillis();
for (int i = size; --i >= 0;) {
int x = a.get(i) + 3;
}
end = System.currentTimeMillis();
System.out.println(end - start
+ " milli seconds for [ int i = size; --i >= 0; ] ");
}
}
Les resultats:
96 milli seconds for [ Integer j : a ]
57 milli seconds for [ int i = 0; i < a.length; i++ ]
31 milli seconds for [ int i = 0; i < size; i++ ]
31 milli seconds for [ int i = size; --i >= 0; ]
Vous pouvez vous faire votre propre opinion, mais trop d'attribution est donnée à l'optimiseur JVM. Vous devez toujours être intelligent avec votre propre code et utiliser for : each la notation n'est PAS une bonne idée (presque jamais). Comme vous pouvez le voir, vous avez une bonne idée en mettant la taille dans sa propre variable.
Même si certaines de ces optimisations peuvent dépendre de la JVM (et certaines peuvent démarrer avec le JIT), il est important de savoir ce que Java fait et ce que Java ne fait pas.
La JVM ne peut pas l'optimiser car size() est une méthode, et JVM ne peut pas (et n'essaiera pas de) déterminer que size() renverra toujours la même valeur dans ce le contexte. Pourvu que la valeur de size() ne change pas, la seconde est légèrement plus performante, mais le gain est tellement, si faible que vous n'avez même pas vraiment besoin d'envisager de l'utiliser.
Si les performances sont critiques, utilisez la boucle de compteur simple, mais pour 98% des cas, la clarté et la simplicité du code sont beaucoup plus importantes (comme 1000x ou plus) et vous devez utiliser une boucle pour chaque.
@David souligne que l'utilisation d'un compteur est plus rapide, mais je voudrais souligner que même pour 10 000 entrées, la différence est inférieure à la microseconde.
Si vous avez une collection de plus de 10 000 entrées, il est fort probable que vous ne devriez pas être en force brute itérant sur toutes les possibilités. Il est plus probable qu'une collection avec une recherche comme une carte soit une meilleure solution pour tout ce que vous avez en tête. Si vous avez bien moins de 10 000 entrées, les performances sont moins susceptibles d'être importantes.
Le comportement est différent si la liste de tableaux change pendant l'itération. Mais je suppose que vous ne faites pas ça. Selon mon test, ce dernier est généralement plus rapide (spécialement sur des systèmes comme Android). Je l'écrirais comme suit:
for (int i = 0, size = flowers.size(); i < size; i++) {
...
}
À partir de la spécification de langage Java (14.14.1):
L'instruction for de base exécute du code d'initialisation, puis exécute une expression, une instruction et du code de mise à jour à plusieurs reprises jusqu'à ce que la valeur de l'expression soit fausse.
L'expression est i < flowers.size() dans votre premier exemple et elle est évaluée une fois à chaque itération. Dans votre cas particulier, cela ne devrait pas faire de différence notable, car flowers.getSize() on ArrayList est une méthode très courte. Mais, en général, si le résultat de l'expression est le même pour chaque itération et coûteux, faites un pré-calcul.
Conséquence: cela doit produire la même sortie dans chaque implémentation d'une machine virtuelle Java et prouve que Expression est évalué une fois à chaque itération:
int counter2 = 10;
for (int counter1 = 0; counter1 < counter2; counter1++) {
System.out.println(counter1 + ", " + counter2);
counter2--;
}
Production:
0, 10
1, 9
2, 8
3, 7
4, 6
La meilleure option est
[ int i = 0; i < size; i++ ]
Vos résultats varieront en fonction de la JVM et d'autres paramètres tels que -client vs -server car certaines des mesures sont si minuscules que vous devez utiliser des nano secondes pour mesurer, et vous devez faire de nombreux tests sinon vous vous retrouvez avec le GC en train de jouer avec Les resultats. De plus, ces types de tests ont l'habitude que la JVM optimise la boucle pour rien. J'ai essayé d'éliminer ce risque en mettant à l'écran la variable qu'il modifie à la fin du code.
1.6
-server
7.968242071 milli seconds for [ Integer j : a ]
7.206275775999999 milli seconds for [ int i = 0; i < a.length; i++ ]
1.5864E-5 milli seconds for [ int i = 0; i < size; i++ ]
14.774186076999998 milli seconds for [ int i = size; --i >= 0; ]
-client
83.36101683999999 milli seconds for [ Integer j : a ]
44.288568631 milli seconds for [ int i = 0; i < a.length; i++ ]
2.3191E-5 milli seconds for [ int i = 0; i < size; i++ ]
24.826621246 milli seconds for [ int i = size; --i >= 0; ]
1.7
-server
7.029150422 milli seconds for [ Integer j : a ]
6.6269827779999995 milli seconds for [ int i = 0; i < a.length; i++ ]
1.3852E-5 milli seconds for [ int i = 0; i < size; i++ ]
13.842110377 milli seconds for [ int i = size; --i >= 0; ]
13.868426141 milli seconds for [ int i = a.size()-1; i >= 0; i-- ]
1.6618000000000003E-5 milli seconds for [ int i = 0; i < a.size(); i++ ]
-client
7.382479727 milli seconds for [ Integer j : a ]
6.748068759 milli seconds for [ int i = 0; i < a.length; i++ ]
1.4162999999999998E-5 milli seconds for [ int i = 0; i < size; i++ ]
13.951547335999999 milli seconds for [ int i = size; --i >= 0; ]
13.929234053999998 milli seconds for [ int i = a.size()-1; i >= 0; i-- ]
1.6873E-5 milli seconds for [ int i = 0; i < a.size(); i++ ]
Code de test:
public static void main(String s[]) {
long start=0, end = 0, delta = 0;
//int[] a = new int[2500000];
List<Integer> a = new ArrayList<Integer>();
int x = 0;
for (int i = 0; i < 2500000; i++) {
a.add(i);
}
start=0; end = 0; delta = 0;
for (int ctr = 0; ctr < 1000; ctr++) {
start = System.nanoTime();
for (Integer j : a) {
x = j + 3;
}
end = System.nanoTime();
delta += end - start;
}
System.out.println(Math.pow(10, -6) * delta / 1000 + " milli seconds for [ Integer j : a ] ");
start=0; end = 0; delta = 0;
for (int ctr = 0; ctr < 1000; ctr++) {
start = System.nanoTime();
for (int i = 0; i < a.size(); i++) {
x = a.get(i) + 3;
}
end = System.nanoTime();
delta += end - start;
}
System.out.println(Math.pow(10, -6) * delta / 1000 + " milli seconds for [ int i = 0; i < a.length; i++ ] ");
int size = a.size();
start=0; end = 0; delta = 0;
for (int ctr = 0; ctr < 1000; ctr++) {
start = System.currentTimeMillis();
for (int i = 0; i < size; i++) {
x = a.get(i) + 3;
}
end = System.currentTimeMillis();
delta += end - start;
}
System.out.println(Math.pow(10, -6) * delta / 1000 + " milli seconds for [ int i = 0; i < size; i++ ] ");
start=0; end = 0; delta = 0;
for (int ctr = 0; ctr < 1000; ctr++) {
start = System.nanoTime();
for (int i = size; --i >= 0;) {
x = a.get(i) + 3;
}
end = System.nanoTime();
delta += end - start;
}
System.out.println(Math.pow(10, -6) * delta / 1000 + " milli seconds for [ int i = size; --i >= 0; ] ");
start=0; end = 0; delta = 0;
for (int ctr = 0; ctr < 1000; ctr++) {
start = System.nanoTime();
for (int i = a.size()-1; i >= 0; i--) {
x = a.get(i) + 3;
}
end = System.nanoTime();
delta += end - start;
}
System.out.println(Math.pow(10, -6) * delta / 1000 + " milli seconds for [ int i = a.size()-1; i >= 0; i-- ] ");
start=0; end = 0; delta = 0;
for (int ctr = 0; ctr < 1000; ctr++) {
start = System.currentTimeMillis();
for (int i = 0; i < a.size(); i++) {
x = a.get(i) + 3;
}
end = System.currentTimeMillis();
delta += end - start;
}
System.out.println(Math.pow(10, -6) * delta / 1000 + " milli seconds for [ int i = 0; i < a.size(); i++ ] ");
System.out.println(x);
}
Ceci est juste une clarification par exemple de la situation.
J'ai testé les exécutions de la "normale" pour la boucle for (int i = 0; i < list.size(); i++) et un micro optimisé pour la boucle for (int i = -1, size = list.size(); ++i < size;). J'ai exécuté les tests dans Eclipse à partir de la ligne de commande et j'ai remarqué une énorme différence.
Résultats de l'exécution dans Eclipse:
Time for Original: 32552 ms Time for MicroOptimized 32707 ms
Fastest Loop: Original
Slowest loop takes 0.47616121897272057% more time
Résultats de l'exécution à partir de la ligne de commande:
Time for Original: 274489 ms Time for MicroOptimized 30516 ms
Fastest Loop: MicroOptimized
Slowest loop takes 799.4920697339101% more time
Ainsi, dans Eclipse, les deux boucles for prennent le même temps, mais lorsqu'elles sont exécutées à partir de la ligne de commande, la version d'origine prend 800% plus de temps que la version microoptimisée. L'ampleur de la différence me souffle l'esprit. Je suppose qu'Eclipse utilise une JVM différente qui applique des astuces d'optimisation intelligentes.
Cela ne signifie pas pour autant que vous devriez commencer à utiliser la version micro optimisée. Dans presque tous les cas, les listes que vous parcourez seront probablement si petites que la différence de performances est négligeable. Et la lisibilité acquise en utilisant la version standard que tout le monde reconnaîtra et comprendra beaucoup plus rapidement est plus avantageuse qu'une augmentation de performance non perceptible.
Pour être complet, voici le code que j'ai exécuté:
public static void main(String[] args) {
List<Byte> list = initializeList();
byte value = 0;
final int NUM_LOOPS = 100;
long startOriginal, startOptimized, endOriginal, endOptimized;
startOptimized = System.currentTimeMillis();
for (int j = 0; j < NUM_LOOPS; j++) {
for (int i = -1, size = list.size(); ++i < size;) {
value = list.get(i);
}
}
endOptimized = System.currentTimeMillis();
startOriginal = System.currentTimeMillis();
for (int j = 0; j < NUM_LOOPS; j++) {
for (int i = 0; i < list.size(); i++) {
value = list.get(i);
}
}
endOriginal = System.currentTimeMillis();
System.out.println(value);
printResults(startOriginal, endOriginal, startOptimized, endOptimized);
}
private static void printResults(long startOriginal, long endOriginal,
long startOptimized, long endOptimized) {
long timeOriginal = endOriginal - startOriginal;
long timeOptimized = endOptimized - startOptimized;
long diff = Math.abs(timeOriginal - timeOptimized);
long min = Math.min(timeOriginal, timeOptimized);
System.out.println("Time for Original: " + timeOriginal + " ms"
+ " Time for MicroOptimized " + timeOptimized + " ms");
System.out.println("Fastest Loop: "
+ ((timeOriginal < timeOptimized) ? "Original"
: "MicroOptimized"));
System.out.println("Slowest loop takes " + ((double) 100 * diff / min)
+ "% more time");
}
public static List<Byte> initializeList(){
List<Byte> list = new ArrayList<Byte>();
final Byte ONE = new Byte((byte) 1);
for (int i = 0; i < Integer.MAX_VALUE / 10; i++) {
list.add(ONE);
}
return list;
}
}
En outre, si vous vous demandez si l'utilisation d'un appel de méthode en tant que collection source a des implications en termes de performances. C'est-à-dire que la méthode sera appelée plusieurs fois - la réponse est non. Voici un exemple:
import Java.util.*;
public class TestForeach {
public static void main (String[] args) {
for (String s : getStrings()) {
System.out.println("The string was: "+s);
}
}
private static List<String> getStrings() {
System.out.println("IN GET STRINGS");
return Arrays.asList("A","B","C");
}
}
Cela se traduira par:
IN GET STRINGS
The string was: A
The string was: B
The string was: C
Par conséquent, la méthode ne sera appelée qu'une seule fois.
Simple mais efficace
for (ConfigDataModel.VisaTypesBean.AddedBean visatype : visaTypesBeans) {
if (visatype.getId() == 24) {
}
Soit on fera l'affaire. Selon la machine virtuelle Java, la seconde peut être plus rapide de quelques cycles d'horloge, mais ce sera une différence incommensurable ou insignifiante. Méfiez-vous de ces types de sous-optimisations. À moins que vous ne construisiez un système en temps réel, où chaque tick du CPU compte, ils ajoutent simplement de la complexité et plus de sources d'erreurs.
Je suggérerais d'utiliser la construction de l'itérateur (comme cela a déjà été suggéré)
For (Flower flower: flowers) { ...
C'est clair, flexible et prédictif.
Pour éviter toute cette numérotation et les itérateurs et vérifications par écrit du code, utilisez le code simple le plus lisible suivant qui a ses performances au maximum. Pourquoi cela a des performances maximales (les détails sont à venir)
for (Object object : aCollection) {
// Do something here
}
Si l'index est nécessaire alors: Pour choisir entre les deux formes ci-dessus: La seconde est la meilleure parce que vous utilisez une variable locale pour vérifier. Lorsque la méthode est quittée, la variable est placée dans la corbeille de la pile.
Mon approche est un peu différente sur ce problème. Pour moi, peu importe la méthode que vous choisissez. la raison en est "l'amélioration des performances" que vous obtiendrez dans la meilleure méthode optimisée sera ~ 50 ms pour 2 500 000 itérations !! (selon @ David's post). Et évidemment, cette amélioration n'est pas quelque chose comme vous voudriez perdre votre temps précieux à trouver une solution optimisée.
(Mais tout de même, conformément à la question initiale de l'OP, je voudrais également suggérer la dernière approche.)
Je sais que la réponse est un peu bizarre et peu commune, mais c'est la réalité.