[ nice-Bugs-875682 ] extended for loop performance

Bugs item #875682, was opened at 2004-01-12 13:20
Message generated for change (Settings changed) made by igouy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112788&aid=875682&group_id=12788

Category: None
Group: None
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Isaac Gouy (igouy)
Assigned to: Nobody/Anonymous (nobody)
Summary: extended for loop performance

Initial Comment:
Lies, damn lies & benchmarks!

Probably I'm making an obvious mistake and comparing 
entirely different things.  These numbers seem a little 
strange. (average of 10, code attached)

19653.2ms extended for, range
12951.5ms foreach, range

83364.1ms extended for, int[]
66637.5ms foreach, int[]
11343.7ms while, int[]

22995.3ms extended for, ArrayList<int>
15753.1ms foreach, ArrayList<int>
17650.0ms while, ArrayList<int>

309.4ms empty while loop

The extended for statement is very convenient - why 
the performance penalty compared to foreach?

----------------------------------------------------------------------

Comment By: Daniel Bonniot (bonniot)
Date: 2004-01-17 10:17

Message:
Logged In: YES 
user_id=88952

Can this be closed, or are there still important performance
issues?


----------------------------------------------------------------------

Comment By: Arjan Boeijink (arjanb)
Date: 2004-01-17 09:15

Message:
Logged In: YES 
user_id=688815

results of benchmark for comparison:

orginal:
57.242s extended for, int[]
48.51s foreach, int[]
8.372s while, int[]

specialized rawArray:
17.215s extended for, int[] as list
12.157s foreach, int[] as list
8.182s while, int[]


----------------------------------------------------------------------

Comment By: Arjan Boeijink (arjanb)
Date: 2004-01-17 08:52

Message:
Logged In: YES 
user_id=688815

This issue is partially solved now(in cvs at least). When an 
array is used as list the performance isn't that bad anymore.
But methods defined for generic arrays will still be slow.

----------------------------------------------------------------------

Comment By: Arjan Boeijink (arjanb)
Date: 2004-01-13 11:29

Message:
Logged In: YES 
user_id=688815

I don't think Java 1.5 will make any difference. Java 1.5 is 
quite limited with generic arrays, such as new T[10] is not 
allowed.

The performance of primitive arrays should definitly be 
improved before version 1.0

----------------------------------------------------------------------

Comment By: Isaac Gouy (igouy)
Date: 2004-01-13 11:07

Message:
Logged In: YES 
user_id=536291

Maybe we'll see changes with Java 1.5

int[] performance is so contrary to naive expectations.

Guess I have a use for the 'user defined statement' - wrap 
foreach as a variation of extended for ;-)

----------------------------------------------------------------------

Comment By: Arjan Boeijink (arjanb)
Date: 2004-01-13 10:44

Message:
Logged In: YES 
user_id=688815

After a closer look these benchmark results can be explained.

An extended for uses a normal iterator and a foreach is in 
principle faster than using an iterator. An Iterator stores the 
current position in a field and the hasNext method cost at 
least 2 fieldaccess while foreach can do the same with 
localvariables. But foreach will loose when it's used with a 
closure that captures multiple variables because that cost 
fieldaccesses too.

I'm surprised by how well the jvm is able to optimize the use 
of function objects :-)

Some of the smaller differences are caused by the number of 
auto(un)boxing of primitives. The compiler does nothing to 
reduce them and in some cases the compiler is just stupid. 
This issue can certainly be improved.

Iterating over primitive arrays is so slow because it uses 
methods defined for generics arrays and the usage of them is 
compiled to calls to java.lang.reflect.Array.{get,set,lenght} 
and that is 10 to 20 times slower than using a normal array. 
Generating versions of these methods for all primitive arrays 
might be possible but it's an awkward solution (won't work for 
generic array fields either). I'm thinking about a solution that 
would make the cost of generic arrays less than 2 times a 
normal array.

explaination for the results:

19653.2ms extended for, range // more autoboxing + iterator 
overhead
12951.5ms foreach, range 

83364.1ms extended for, int[] // generic array overhead + 
more autoboxing  + iterator overhead
66637.5ms foreach, int[] // generic array overhead
11343.7ms while, int[] 

22995.3ms extended for, ArrayList // more autoboxing + 
iterator overhead
15753.1ms foreach, ArrayList // jvm doing a good job
17650.0ms while, ArrayList // stupid auto-unbox followed by 
autobox

----------------------------------------------------------------------

Comment By: Arjan Boeijink (arjanb)
Date: 2004-01-12 13:49

Message:
Logged In: YES 
user_id=688815

Surprising benchmarks I would say. The int array is doing 
badly because it's converted to an object array and I know 
that foreach and extended for aren't tuned yet. But I will try 
to improve the numbers for Nice a bit.

BTW I don't see an attachment with the code.

----------------------------------------------------------------------

Comment By: Isaac Gouy (igouy)
Date: 2004-01-12 13:23

Message:
Logged In: YES 
user_id=536291

Warning: this takes 30 minutes or so on P4 2GHz WinXP

java version "1.4.2_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 
1.4.2_01-b06)
Java HotSpot(TM) Client VM (build 1.4.2_01-b06, mixed mode)

Nice compiler version 0.9.6 prerelease (build 2004.01.10, 
17:42:12 UTC)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112788&aid=875682&group_id=12788


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn