Updated foreach itterator to use a for loop

[GoogleCodeExporter]

Java's foreach method creates a new iterator class each time it's run. This is 
a redundant when used on an ArrayList.

The attached patch changes the use of foreach to a for resulting in a 20% 
games/second increase on my machine.

Original issue reported on code.google.com by nafets...@gmail.com on 24 Nov 2010 at 7:04

Attachments:

• Patch3.patch

[GoogleCodeExporter]

The behavior for this patch is interesting.
It really increased the performance from ~1700 g/s to ~1910 g/s using 1 
processor and only the final waypoint (7 mutalisk 1 flyer attack) but the 
performance significantly dropped when waypoints were being used. So for wp0 6 
lings, wp1 6 roach, wp2 2 hydra, wp3 3 overseers and final 7 muta 1 flyer 
attack the performance dropped from ~1400-1500 g/s to ~1350-1400 g/s.
Can someone test to see if they can observe the same performance drop for more 
waypoints in use compared to the version without the patch (same goals in each 
waypoint)?

Original comment by netpr...@gmail.com on 24 Nov 2010 at 8:47

[GoogleCodeExporter]

Original comment by netpr...@gmail.com on 24 Nov 2010 at 8:47

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

http://stackoverflow.com/questions/1879255/traditional-for-loop-vs-iterator-in-j
ava
Some of the comments state that the iterator might be faster because of 
avoiding the size() calculation. Also I think it avoids checking for out of 
bounds access like the method .get() enforces.

Original comment by netpr...@gmail.com on 24 Nov 2010 at 8:55

[GoogleCodeExporter]

While the performance should be the same for the iterator and the for loop the 
main difference is that the iterator creates a new class every time it is 
called, which is a rather large number of times. 

If you're worried about the extra size calculation on each iteration that can 
be moved outside of the for loop, though I saw no difference in time.

As for the waypoints I noticed no difference in games per second before or 
after the patch.

Original comment by nafets...@gmail.com on 24 Nov 2010 at 9:11

[GoogleCodeExporter]

OK, then I'm assuming that the drop was due to other activity on this machine. 
The change in g/s was so small that this actually might have been the case.
I'm committing your patch. Also setting Lomilar as the Cc on this issue as I 
think you should get commit privileges :)

Original comment by netpr...@gmail.com on 24 Nov 2010 at 9:20

• Changed state: Accepted
• Added labels: Performance

[GoogleCodeExporter]

Fixed in r134

Original comment by netpr...@gmail.com on 24 Nov 2010 at 9:23

• Changed state: Fixed

[GoogleCodeExporter]

Original comment by netpr...@gmail.com on 24 Nov 2010 at 9:39

• Added labels: Milestone-0023

[GoogleCodeExporter]

I did some speed tests to look at how much this patch improved performance.  
Using the two different kinds of tests that netprobe used in  issue 158  (one 
with and one without waypoints), I calculated the average games played per 
second with two different versions of the application (before and after the 
patch).  The two tests are described below.

Before running each test, I deleted the "etc" directory and restarted Evolution 
Chamber to avoid caching or memory issues that might effect performance.  Each 
test used 1 processor and ran for 20 seconds.  The average games played per 
second was calculated using code that I added to the application.  I didn't 
check the resulting build order for accuracy...I only focused on the speed.

Test 1:
Final: 7 Mutas, +1 Flyer Attack

Test 2:
WP0: 6 Zerglings
WP1: 6 Roaches
WP2: 2 Hydralisks
WP3: 3 Overseers
Final: 7 Mutalisks, +1 Flyer Attack

==========

Before patch (r133):
Test 1: 1759.2064123080545
Test 2: 2034.8954968418927

After patch:
Test 1: 2171.0298917603272175 (~20% increase)
Test 2: 2204.355442127818 (~7% increase)

Original comment by mike.angstadt on 29 Nov 2010 at 11:23