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
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
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
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, 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
