i'd recommend you do a quick benchmark of your own when choosing a collection other than the one with the offical jre, last time i tried a different collection FastList from http://javolution.org/ although according to the website the benchmarks for FastList are better than ArrayList, my own tests showed otherwise.

Optimisations are always taking place here and there with every new release of java release. I've found java collection to be pretty sufficient perfomance wise and you should only be worried if it becomes a bottle neck as mentioned above.

i've found that ArrayLists are really good for java gaming, they're fast and easy to use, much nicer than using arrays.

P.S. another thing that i've found is that ArrayLists are almost always faster than LinkedLists.

Completely the opposite of my experience. Which I only mention in order to say "YMMV", and "quotes like the above which have no explanation are useless information, you need to go away and look at the documentation and make an informed decision for yourself - whether by benchmarking or algorithm or code analysis".

For an example: Java 1.4.2 and perhaps 1.5 too (can't remember) ArrayList collapses completely if you go to large data sets (more than a few thousand entries in a single list). Performance drops by orders of magnitude.

For an example: Java 1.4.2 and perhaps 1.5 too (can't remember) ArrayList collapses completely if you go to large data sets (more than a few thousand entries in a single list). Performance drops by orders of magnitude.

most game types won't need to have more than a few hundred entities at anyone time anyway, so i doubt you'd run into the data set too large thing you mention. Besides entities you finish with can easily be removed. Only thing i can think of that'd require massive amount of entities is a particle manager for which you shouldn't need to use an arraylist anyway, for which a normal array should suffice.

A List implementation that is optimised for fast insertions and removals at any index in the list.

This list implementation utilises a tree structure internally to ensure that all insertions and removals are O(log n). This provides much faster performance than both an ArrayList and a LinkedList where elements are inserted and removed repeatedly from anywhere in the list.

The following relative performance statistics are indicative of this class:

ArrayList is a good general purpose list implementation. It is faster than TreeList for most operations except inserting and removing in the middle of the list. ArrayList also uses less memory as TreeList uses one object per entry.

LinkedList is rarely a good choice of implementation. TreeList is almost always a good replacement for it, although it does use sligtly more memory.

but commons collections doesn't support genetrics afaik. I haven't used this but I just bumbed into it then I saw this discussion.

The problem with ArrayLists *is* removing of Objects, as all objects right of it, must be shifted to the left.

If you're doing that (adding/inserting/removing) very often per frame it can very well become a bottleneck.

So surely you can copy the last element of your arraylist to the position of the element to be removed, and simply remove the last element of the arraylist? Wouldn't that just be a reference copy and then a removal with no shifting?

So surely you can copy the last element of your arraylist to the position of the element to be removed, and simply remove the last element of the arraylist? Wouldn't that just be a reference copy and then a removal with no shifting?

Speaking of lists and performance; last night, i made a class (aptly named OverwriteList) that is half Map, half List, half Buffer. It implements List<MutableEntry<K, V>>, encapsulates List<MutableEntry<K, V>> and holds an index counter, on add(...), the counter would be increased, then you could try to get from the MutableEntry<K, V> from the list, if an IndexOutOfBoundsException is thrown, then you just use the encapsulated list's add(...) method, if not, then you you get the MutableEntry<K, V> at that index, and set the key and value of the current entry to the one that you want to add. A clear() would be simply resetting the index back to 0.

Extremely useful when you want to have a 1 - 1 relationship between two objects (sorta like a hashmap) and need minimum garbage creation (renderbins anyone? )

So surely you can copy the last element of your arraylist to the position of the element to be removed, and simply remove the last element of the arraylist? Wouldn't that just be a reference copy and then a removal with no shifting?

That would work unless the order the elements are in matters.

didn't realise that removing objects caused such a performance hit for ArrayLists, so if you need to remove an object on a list where order doesn't matter with a lower performance hit, how would you do it?

here my attempt not sure if its right

1 2 3 4 5

intindex; // index of entity that needs removingintlast = myArrayList.size() - 1; // index of last entity in the list

I wanted to know what this would mean in reality... so I took my (opengl accelerated) fuzetsu prototype and replaced the ArrayLists with Bag. With about 1600 bullets I got 80fps instead of 60fps (on a 500mhz machine!).

Really awesome

edit: Btw with 1.5.0_07 and up using a get() wrap for the direct array acess is about equally fast. With 1.5.0_06 and earlier its about 30% slower.

I wanted to know what this would mean in reality... so I took my (opengl accelerated) fuzetsu prototype and replaced the ArrayLists with Bag. With about 1600 bullets I got 80fps instead of 60fps (on a 500mhz machine!).

Really awesome

edit: Btw with 1.5.0_07 and up using a get() wrap for the direct array acess is about equally fast. With 1.5.0_06 and earlier its about 30% slower.

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