Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (517)
Games in Android Showcase (123)
games submitted by our members
Games in WIP (578)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  ArrayList performance on 1.4.2 is good  (Read 2935 times)
0 Members and 1 Guest are viewing this topic.
Offline shawnkendall

Senior Duke





« Posted 2003-10-27 15:41:43 »

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. :-)  For those who weren't (read C game developers reviewing Java) our position is that it is now an option.

Shawn Kendall
Cosmic Interactive, LLC
http://www.facebook.com/BermudaDash
Offline Herkules

Senior Duke




Friendly fire isn't friendly!


« Reply #1 - Posted 2003-10-27 15:54:39 »

Very good to hear Smiley

So I don't have to change my code.

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

HARDCODE    --     DRTS/FlyingGuns/JPilot/JXInput  --    skype me: joerg.plewe
Offline William

Junior Duke




No Exit


« Reply #2 - Posted 2003-10-27 16:19:26 »

Nice to hear Smiley 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?
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline shawnkendall

Senior Duke





« Reply #3 - Posted 2003-10-27 23:53:28 »

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" ?:-)

Shawn Kendall
Cosmic Interactive, LLC
http://www.facebook.com/BermudaDash
Offline princec

JGO Kernel


Medals: 409
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #4 - Posted 2003-10-28 07:38:37 »

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 Smiley

Offline Java Cool Dude

Senior Duke




Java forever


« Reply #5 - Posted 2003-10-28 07:50:04 »

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

Senior Duke


Medals: 9
Exp: 16 years


Java games rock!


« Reply #6 - Posted 2003-10-28 08:04:04 »

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.
Offline Jeff

JGO Coder




Got any cats?


« Reply #7 - Posted 2003-10-28 17:56:12 »

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.

Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline Athomas Goldberg

Junior Duke




Grrrrrr...


« Reply #8 - Posted 2003-10-29 02:11:08 »

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.

For the same reasons, if you *do* need a synchronized list it's recommended that you use Collections.synchronizedList() rather than Vector.

Athomas Goldberg
Project Lead / Wildcard
Game Technologies Group
Sun Microsystems, Inc.
Offline MickeyB

Senior Duke




my game will work, my game will work!


« Reply #9 - Posted 2003-11-25 15:48:38 »

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

MickeyB

Current Project: http://www22.brinkster.com/mbowles/
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline tom
« Reply #10 - Posted 2003-11-25 17:03:10 »

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.

Offline MickeyB

Senior Duke




my game will work, my game will work!


« Reply #11 - Posted 2003-11-25 17:21:25 »

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

M

MickeyB

Current Project: http://www22.brinkster.com/mbowles/
Offline Seekely

Senior Newbie




I am java


« Reply #12 - Posted 2003-11-26 12:08:46 »

Quote
Nice to hear Smiley 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?



Isn't this and the casting feature they are adding simply going to be dirty compiler tricks instead of at runtime?

http://www.untoldevils.com  
An RPG like every other, except this one is made by me
Offline William

Junior Duke




No Exit


« Reply #13 - Posted 2003-11-26 20:22:08 »

Quote
Isn't this and the casting feature they are adding simply going to be dirty compiler tricks instead of at runtime?

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.
Offline swpalmer

JGO Coder


Exp: 12 years


Where's the Kaboom?


« Reply #14 - Posted 2003-11-27 03:45:39 »

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.


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.

Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

DarkCart (23 views)
2014-10-31 21:44:48

DarkCart (29 views)
2014-10-31 21:43:57

TehJavaDev (40 views)
2014-10-27 03:28:38

TehJavaDev (31 views)
2014-10-27 03:27:51

DarkCart (45 views)
2014-10-26 19:37:11

Luminem (27 views)
2014-10-26 10:17:50

Luminem (31 views)
2014-10-26 10:14:04

theagentd (36 views)
2014-10-25 15:46:29

Longarmx (64 views)
2014-10-17 03:59:02

Norakomi (62 views)
2014-10-16 15:22:06
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!