J'aimerais demander aux développeurs plus expérimentés sur un simple, mais pour moi pas évident, chose. Supposons que vous avez un tel code (Java): J'ai rencontré de telles déclarations très souvent, alors peut-être qu'il n'y a rien de mal à cela. Mais pour moi, il semble inutile d'invoquer une méthode de taille dans chaque itération. J'utiliserais une telle approche: p> la même chose ici: p> Je ne suis certainement pas un expert en programmation encore , alors ma question est la suivante: suis-je à la recherche d'un écart où la haie est entière ou qu'il est important de prendre soin de tels détails dans le code professionnel? p> p>
3 Réponses :
Une invocation de méthode nécessite que le JVM fasse effectivement des choses supplémentaires. Alors, qu'est-ce que vous faites, à la première vue semble être une optimisation. P>
Cependant, certaines implémentations JVM sont suffisamment intelligentes pour les appels de méthode en ligne, et pour ceux-ci, la différence sera inexistante. P>
Les directives de programmation Android, par exemple recommandant de faire ce que vous avez signalé, mais encore une fois, le manuel de mise en œuvre JVM (si vous pouvez mettre la main sur une) vous indiquera s'il optimise le code pour vous ou non. p>
généralement Cela dit, cette optimisation n'affecte pas de manière défavorable la lisibilité du code. Ce n'est donc pas quelque chose à éviter; Souvent, les optimisations de code qui n'affectent que la vitesse par un faible facteur (par exemple à une optimisation qui modifie une opération O (n) à une opération O (1)) doivent être évitées pour cette raison, par exemple, vous pouvez en déroulant la boucle quatre fois que vous Réduisez le nombre de fois que taille () code> est une petite opération à temps constant et donc le coût de l'appelant la taille code> est trivial par rapport au coût de l'exécution du corps de la boucle et du juste Dans le temps, le compilateur peut prendre soin de cette optimisation pour vous; Par conséquent, il peut ne pas y avoir beaucoup d'avantages à cette optimisation. i code code> est évalué d'un facteur de quatre, au coût de la fabrication de votre code un désordre illisible (il peut également faire échec au cache d'instructions, entraînant un impact négatif sur la performance. ). Ne fais pas ça. Mais, comme je l'ai dit, int Vectorsize = vector.size () code> ne tombe pas dans cette catégorie, de même en avoir. P> P>
Mais bien sûr, comme le soupçonnait le garçon, une opération de temps constante prend plus d'une opération de non-temps. belle contribution cependant;)
À la 1ère vue, l'alternative que vous suggérez des coutures une optimisation, mais en termes de vitesse, il est identique em> à l'approche commune, à cause de: p>
Le temps de complexité de la fonction d'appel de taille () dans un vecteur Java a une complexité de commande O (1) puisque chaque vecteur a toujours stocké une variable contenant sa taille, de sorte que vous n'avez pas besoin de calculer sa taille dans Chaque itération, vous venez d'y accéder. P>
note:
Vous pouvez voir que la taille de la taille () de: http: // www.docjar.com/html/api/java/util/vector.java.html ne fait que renvoyer une variable protégéeCount. P>
Merci - j'ai eu des problèmes de recherche de réponse pour cette question ...
Parfois, vous modifiez la taille du vecteur à l'intérieur de la boucle. Il n'y a rien de mal à obtenir la taille au préalable, surtout si l'appel de taille est cher. La taille de vecteur n'est pas un appel coûteux, cependant. Il suffit de comprendre pourquoi vous obtiendrez la taille avant de commencer la boucle et de comprendre pourquoi vous souhaitez vérifier la taille après chaque itération de la boucle.