blocks|key|1164278|text|永远不要为了性能而编码，总是为了可读性而编码。让编译器来做这项工作。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1164279|它们可以改善编译器/运行时以更快地运行好的代码，而突然之间你的“快速”代码实际上减慢了系统的速度。|1164280|Java编译器和运行时优化似乎首先处理更常见/可读的代码，因此您的“优化”代码更有可能在以后被取消优化，而不是刚刚干净地编写的代码。|1164281|注意：|1164282|这个答案指的是像上面提到的问题一样的Java代码“技巧”，这不是一个糟糕的编程，它可能会将循环的级别从O(N)提高到O(N%5E2)。一般情况下，编写干净、干燥的代码，并在修复操作之前等待明显太长的时间。除非你是一名游戏设计师，否则你几乎永远不会达到这一点。|1164283|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|N|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|O|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

Never code for performance, always code for readability. Let the compiler do the work.

They can improve the compiler/runtime to run good code faster and suddenly your "Fast" code is actually slowing the system down. 

Java compiler &amp; runtime optimizations seem to address more common/readable code first, so your "Optimized" code is more likely to be de-optimized at a later time than code that was just written cleanly.

Note:

This answer is referring to Java code "Tricks" like the question referenced, not bad programming that might raise the level of loops from an O(N) to an O(N^2). Generally write clean, DRY code and wait for an operation to take noticeably too long before fixing it. You will almost never reach this point unless you are a game designer.

blocks|key|1164178|text|你的线索是正确的。在VM的现代版本中，返回私有字段的简单getter是内联的，这意味着不存在方法调用的性能开销。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1164179|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Your lead is correct. In modern versions of the VM, simple getters that return a private field are inlined, meaning the performance overhead of a method call doesn't exist.

blocks|key|1164494|text|不要忘记，通过将getSomething()的值赋给一个变量而不是调用它两次，您假定getSomething()会在您第二次调用它时返回相同的内容。在您正在讨论的场景中，这可能是一个有效的假设，但有时不是。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1164495|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Don't forget that by assigning the value of getSomething() to a variable rather than calling it twice, you are assuming that getSomething() would have returned the same thing the second time you called it. Perhaps that's a valid assumption in the scenario you are talking about, but there are times when it isn't.

blocks|key|1379357|text|如果您牢记代码演变，那么v1.0中的简单getter往往在v2.0中变得不那么简单。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1379358|将一个简单的getter更改为不那么简单的getter的程序员通常不知道有一个函数调用这个getter+10次而不是1次，并且永远不会在那里纠正它，等等。|1379359|这就是为什么从DRY+principal的角度来看，缓存值以供重复使用是有意义的。|offset|length|1379360|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/Don%2527t_repeat_yourself^0|0|0|7|D|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@$F|S|G|T|1|U]]|A|$]]|$1|H|3|-4|5|6|7|V|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|O]]]]

If you keep the code evolution in mind, simple getters in v1.0 tend to become not-so-simple getters in v2.0.

The coder who changes a simple getter to not-so-simple getter usually has no clue that there is a function that calls this getter 10 times instead of 1 and never corrects it there, etc.

That's why from the point of view of the <a href="http://en.wikipedia.org/wiki/Don%27t_repeat_yourself" rel="noreferrer">DRY principal</a> it makes sense to cache value for repeated use.

blocks|key|1164690|text|我不会为了几微秒而牺牲“代码可读性”。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1164691|也许getter的性能更好，并且可以在运行时为您节省几微秒。但我相信，当修复bug的时间到来时，变量可以为您节省几个小时，甚至几天。|1164692|对于非技术性的回答，我很抱歉。|1164693|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

I will not sacrifice "Code readability" to some microseconds. 
Perhaps it is true that getter performs better and can save you several microseconds in runtime. But i believe, variables can save you several hours or perhaps days when bug fixing time comes. 

Sorry for the non-technical answer.

blocks|key|1379261|text|我认为JVM的最新版本通常足够聪明，可以在满足某些条件的情况下自动缓存函数调用的结果。我认为函数必须没有副作用，并且每次调用时都可靠地返回相同的结果。请注意，对于简单的getter，这可能是也可能不是这种情况，这取决于您的类中的其他代码对字段值所做的操作。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1379262|如果不是这样，并且被调用的函数进行了大量的处理，那么您最好将其结果缓存到一个临时变量中。虽然调用的开销可能微不足道，但如果您不必要地频繁调用一个繁忙的方法，它将会吞噬您的午餐。|1379263|我还实践了您的风格；即使不是出于性能原因，我也会发现当代码中没有层叠的函数调用时，代码会更易读。|1379264|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

I think that recent versions of the JVM are often sufficiently clever to cache the result of a function call automatically, if some conditions are met. I think the function must have no side effects and reliably return the same result every time it is called. Note that this may or may not be the case for simple getters, depending on what other code in your class is doing to the field values.

If this is not the case and the called function does significant processing then you would indeed be better of caching its result in a temporary variable. While the overhead of a call may be insignificant, a busy method will eat your lunch if you call it more often than necessary.

I also practice your style; even if not for performance reasons, I find my code more legible when it isn't full of cascades of function calls.

blocks|key|1379817|text|如果仅仅是getFoo()，那就不值得了。通过将其缓存到temp变量中，您不会使它变得更快，而且可能会自找麻烦，因为getFoo()稍后可能会返回不同的值。但是，如果它类似于getFoo().getBar().getBaz().getSomething()，并且您知道该值不会在代码块中更改，那么可能有理由使用temp变量以获得更好的可读性。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1379818|entityMap^0|5|8|1M|8|2F|15|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]|$9|K|A|L|B|C]|$9|M|A|N|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|O|8|@]|D|@]|E|$]]]|G|$]]

It is not worth if it is just <code>getFoo()</code>. By caching it into a temp variable you are not making it much faster and maybe asking for trouble because <code>getFoo()</code> may return different value later. But if it is something like <code>getFoo().getBar().getBaz().getSomething()</code> and you know the value will not be changed within the block of code, then there may be a reason to use temp variable for better readability.

blocks|key|1379417|text|一般评论:在任何现代系统中，除了I/O，不要担心性能问题。高速的CPU和大量的内存意味着，在大多数情况下，所有其他问题对系统的实际性能都是无关紧要的。当然，也有像缓存解决方案这样的例外，但它们非常罕见。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1379418|现在谈到这个特定的问题，是的，编译器将内联所有的get。然而，即使这不是真正的考虑因素，真正重要的是代码的可读性和流畅性。如果调用被多次使用，那么用局部变量替换间接地址会更好，比如customer.gerOrder().getAddress()在局部变量中捕获效果更好。|1379419|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

A general comment: In any modern system, except for I/O, do not worry about performance issues. Blazing fast CPUs and heaps of memory mean, all other issues are most of the time completely immaterial to actual performance of your system. [Of course, there are exceptions like caching solutions but they are far and rare.]

Now coming to this specific problem, yes, compiler will inline all the gets. Yet, even that is not the actual consideration, what should really matter is over all readability and flow of your code. Replacing indirections by a local variable is better, if the call used multiple times, like customer.gerOrder().getAddress() is better captured in local variable.

blocks|key|1379610|text|虚拟机可以比在那之后声明的任何局部变量更有效地处理前四个局部变量(参见lload+and+lload_+instructions)。因此，缓存(内联)+getter的结果实际上可能会损害您的性能。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1379611|当然，就它们本身而言，性能影响几乎可以忽略不计，因此，如果您想优化代码，请确保您真正解决了一个实际的瓶颈！|1379612|entityMap|0|LINK|mutability|MUTABLE|url|http://java.sun.com/docs/books/jvms/second_edition/html/Instructions2.doc8.html#lload^0|Z|T|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@$A|O|B|P|1|Q]]|C|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|C|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]]]

The virtual machine can handle the first four local variables more efficiently than any local variable declared after that (see <a href="http://java.sun.com/docs/books/jvms/second_edition/html/Instructions2.doc8.html#lload" rel="nofollow noreferrer">lload and lload_&lt;n> instructions</a>). So caching the result of the (inlined) getter may actually hurt your performance.

Of course on their own either performance influence is almost negligible so if you want to optimize your code make sure that you are really tackling an actual bottleneck!

blocks|key|1164642|text|不使用临时变量来包含方法调用结果的另一个原因是，使用该方法可以获得最新的值。对于实际的代码，这可能不是问题，但当代码更改时，这可能会成为一个问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1164643|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Another reason to not use a temporary variable to contain the result of a method call is that using the method you get the most updated value. This could not be a problem with the actual code, but it could become a problem when the code is changed.

blocks|key|1164833|text|我赞成使用temp变量，如果你确信getter会在整个作用域中返回相同的值。因为如果你有一个长度为10或更长的变量，getter在可读性方面看起来很糟糕。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1164834|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I am in favour of using temp variable if you are sure about getter will return same value throughout the scope. Because if you have a variable having name of length 10 or more getter looks bad in readability aspect.

blocks|key|1164886|text|我用%2B1来保存变量。1)可读性优于性能--你的代码不仅仅适合你。2)性能可能可以忽略不计，但不是所有时间。我认为保持一致并开创先例是很重要的。因此，虽然它可能对一个局部变量无关紧要-但在更大的类中使用相同的值多次或在循环的情况下可能会很重要。3)易于更改实现/避免代码枯燥。现在，您可以使用getter从这个位置获取值，理论上，您可以在一个类中使用getter+100次。但是在将来-如果你想改变获取值的位置/方式-现在当你将它保存为实例变量时，你必须改变它100次，而不是只改变一次。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1164887|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I'm +1 for saving the variable. 
1) Readability over performance - your code is not just for you.
2) Performance might be negligible but not all the time. I think it is important to be consistent and set a precedent. So, while it might not matter for one local variable - it could matter in a larger class using the same value multiples times or in the case of looping. 
3) Ease of changing implementation/ avoiding DRY code. For now you get the value from this one place with a getter and theoretically you use the getter 100 times in one class. But in the future - if you want to change where/how you get the value - now you have to change it 100 times instead of just once when you save it as an instance variable.

Recently I got into a discussion with my Team lead about using temp variables vs calling getter methods. I was of the opinion for a long time that, if I know that I was going to have to call a simple getter method quite a number of times, I would put it into a temp variable and then use that variable instead. I thought that this would be a better both in terms of style and performance. However, my lead pointed out that in Java 4 and newer editions, this was not true somewhat. He is a believer of using a smaller variable space, so he told me that calling getter methods had a very negligible performance hit as opposed to using a temp variable, and hence using getters was better. However, I am not totally convinced by his argument. What do you guys think?

Java Method invocation vs using a variable

最近，我和我的团队领导讨论了使用临时变量与调用getter方法的问题。很长一段时间以来，我一直认为，如果我知道我将不得不多次调用一个简单的getter方法，我会将其放入一个temp变量中，然后使用该变量。我认为这在风格和性能方面都会更好。然而，我的lead指出，在Java4和更新版本中，这在某种程度上是不正确的。他相信使用较小的变量空间，所以他告诉我，与使用temp变量相比，调用getter方法的

问Java方法调用与使用变量
EN

回答 12

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Java方法调用与使用变量EN

回答 12

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Java方法调用与使用变量
EN