On 2011-02-04, Jesse Glick wrote:
> On 02/04/2011 09:03 AM, Antoine Levy-Lambert wrote:
>> I did not know that using a final variable for the upper bound of a loop
>> instead of something.size() makes a difference in terms of performance.
> Generally the preferred idiom is to use an iterator,
A
On 02/04/2011 09:03 AM, Antoine Levy-Lambert wrote:
I did not know that using a final variable for the upper bound of a loop
instead of something.size() makes a difference in terms of performance.
Generally the preferred idiom is to use an iterator, which the Java 5 for loop would do if we wer
On 2011-02-04, Antoine Levy-Lambert wrote:
> Hello Stefan,
> I did not know that using a final variable for the upper bound of a
> loop instead of something.size() makes a difference in terms of
> performance. Interesting.
> I just read the original bug report "Project.fireMessageLoggedEvent
> p
It depends on the cost of .size(), it is done on each run of the body
and cannot be optimized by the compiler (.size() could change during
the loop).
A common pattern is to do:
for (int i = 0, len = x.size(); i < len; ++i) {
...
}
Peter
On Fri, Feb 4, 2011 at 2:03 PM, Antoine Levy-Lambert w
Hello Stefan,
I did not know that using a final variable for the upper bound of a loop
instead of something.size() makes a difference in terms of performance.
Interesting.
I just read the original bug report "Project.fireMessageLoggedEvent
performance fix" [1] and the one you have addressed
