ArrayList performance on 1.4.2 is good

Performance Tuning
#1

Hi all,
Well I am quite happy to report that after exhaustive testing, my team is adopted ArrayLists from the java.util/Collections APIs for container functionality in final core game engine classes.

Previous testing on several Collection classes has shown less than please results WRT performance, class size and extraneous garbage collection.

It seems 1.4.2 gc is really handling Collection issues well, so well in fact that we are slowly adopting in more as we see fit. With this adoption, Java 1.5 will also be able to take advantage of the new “for” syntax and run-time benefits.

For us, this is a significant change, as in the past we have publicly “denounced” the Collections APIs in PRODUCTION level game code. For tools and prototyping fine, but high performance, very controlled per frame code, no. With the latest VM (on Windows at least), we can found ArrayLists to be of production level quality when needing a growable/dynamic sized list.

Last years GDC presentation on this topic yielded some interesting (heated) floor discussion about Collections and GCing. In the end, we still did not endorse them. However, this year we will endorse a growing sub-set as testing progresses.

For many of you, this probably means squat as you either didn’t care, or were already convinced on using Collections. :slight_smile: For those who weren’t (read C game developers reviewing Java) our position is that it is now an option.

#2

Very good to hear :slight_smile:

So I don’t have to change my code.

Hm, not too many collections besides HashMap in there anyway … most for listeners and such.

#3

Nice to hear :slight_smile: Now I’m just curious about how the GC and optimizer will perform for primitive collections that use the auto-boxing feature in Java 1.5.

Can, and will, the optimizer make these an alternative to custom-written primitive collections for performance-critical code, or will the boxing/unboxing slow things down too much? Anyone know how well the C# VM optimizes these?

#4

YEAH… that is a good question.
I have seen several very nice “int” HashMaps (not Integer)
Auto-boxing will make it SEEM like “int” but will it run like “int” ?:slight_smile:

#5

Well, obviously not - it’s got to construct an object on the heap somewhere, where it might linger awhile and end up fragmenting memory a bit, and later on it’ll have to garbage collect it at some point. None of which is entirely cost-free, as an int is. It’ll all come down to the nitty-gritty fine detail, as usual…

Cas :slight_smile:

#6

Umm I happen to use Vectors in my 3D application, question now:
Are arrayLists faster than Vectors?

#7

The methods of a Vector are threadsafe (synchronized), where ArrayLists are not. So if you aren’t sharing the collection across threads, ArrayLists are recommended.

#8

I would add further that Vectors are a dead develoment line (same as Hashtable) so UNLESS you need 1.1 compatability use the collection classes instead.

#9

[quote]I would add further that Vectors are a dead develoment line (same as Hashtable) so UNLESS you need 1.1 compatability use the collection classes instead.
[/quote]
For the same reasons, if you do need a synchronized list it’s recommended that you use Collections.synchronizedList() rather than Vector.

#10

Let me get this straight. If I plan to convert my game to multiplayer and have numerous client threads access a “list” of sectors/rooms/whateva, I should use Collections.synchronizedList() to store my list of objects that I will loop through for sending data to clients?

M

#11

Yes. Collections.synchronizedList() will prevent the list from being corrupted when more than one thread is using it. But you would also need additional synchronization to prevent the list from changing while you are iterating it.

#12

thanks tom! Great pic by the way…would have hated to run into it in the pen and paper days. ;D

M

#13

[quote]Nice to hear :slight_smile: Now I’m just curious about how the GC and optimizer will perform for primitive collections that use the auto-boxing feature in Java 1.5.

Can, and will, the optimizer make these an alternative to custom-written primitive collections for performance-critical code, or will the boxing/unboxing slow things down too much? Anyone know how well the C# VM optimizes these?
[/quote]
Isn’t this and the casting feature they are adding simply going to be dirty compiler tricks instead of at runtime?

#14

[quote] Isn’t this and the casting feature they are adding simply going to be dirty compiler tricks instead of at runtime?
[/quote]
The techniques will be performed at compile time, yes. That’s perfectly appropriate for eliminating casts since the only benefits you get from generics are clearer code and compile-time type safety. At least Sun’s VM has optimized away the cost of casts in all the apps I have benchmarked, so performance isn’t an issue there.

I also don’t know of any runtime optimization specificly for autoboxing objects (which is why I asked about it). The object creation optimizations (like generational garbage collection) that Hotspot uses seem to apply to all object allocations, so I can’t see any good reason to break backwards compatability and make autoboxing a part of the VM.

#15

[quote]Yes. Collections.synchronizedList() will prevent the list from being corrupted when more than one thread is using it. But you would also need additional synchronization to prevent the list from changing while you are iterating it.
[/quote]
I find a lot of the time I can just get rid of the synchronized collection because of this extra synchronization that must be added anyway for keeping the list constant while iterating over it.

I the add/remove methods I call have to use this ‘additional’ synchronization anyway, so what good is the synchronization that is built-in? It’s redundant.