I use ArrayLists rather than arrays with current size var because... well, that's what OOP was invented for. So you didn't have to keep doing that sort of crap everywhere. The VM optimises it to the point where it won't make a great deal of difference and as Damocles says, it'll just lead to more errors, duplicated code, and yucky looking code.

I use ArrayLists rather than arrays with current size var because... well, that's what OOP was invented for. So you didn't have to keep doing that sort of crap everywhere. The VM optimises it to the point where it won't make a great deal of difference and as Damocles says, it'll just lead to more errors, duplicated code, and yucky looking code.

+1. Use arrays and you'll slowly start writing your own ArrayList, and probably a suboptimal one at that!

One possible performance improvement, inspired by @theagentd's comment (or maybe exactly what he means?), would be a list that didn't null everything on clear(), just resets the counter, and has a separate cleanup() method that nulls everything past the counter value. Obviously, you call cleanup() every now and again to GC, but if the size of the list remains fairly constant, that should only need to null a few references rather than iterating through everything on every frame.

And it'll be a PITA to implement, and you'll probably gain next to nothing!

Okay then, these are all good points! I guess I haven't worked on a sufficiently-sized project yet to encounter these problems. I'm open to the idea of doing this 1% less efficiënt to make it 10% less error prone

Thanks for the advice, I'll have a good long look at the other approaches described here.

One possible performance improvement, inspired by @theagentd's comment (or maybe exactly what he means?), would be a list that didn't null everything on clear(), just resets the counter, and has a separate cleanup() method that nulls everything past the counter value. Obviously, you call cleanup() every now and again to GC, but if the size of the list remains fairly constant, that should only need to null a few references rather than iterating through everything on every frame.

And it'll be a PITA to implement, and you'll probably gain next to nothing!

The speed of clearing that list to null is incredibly fast. I mean, really, incredibly fast. Even if the list is really, really big. And who knows what benefits it will have on the garbage collector. Probably only positive ones. Premature optimisation ftw!

I will go with double buffered ArrayList. I'm implementing that on my code right now. It works well so far. I'm gonna test around.

I learned several new things from this topic. Very interesting to hear others' opinions. I have to look more into GC to understand better.

In my case, I believe double buffered ArrayList would be more efficient than Bag. Like I said above, I think keeping entities in spawned order is more appropriate. If I was to use Bag to hold entities, I would be looping backwards to enable removing and not missing any element while iterating. If I need a structure to hold static number of things, then I would just go with array or the most simple.

May I ask someone to explain the purpose of the temp ArrayList in princec's code example? Setting entities1 = temp right before you .clear() it seems unnecessary, though I'm sure there is a reason for doing so. Is this done to help java's garbage collector?

May I ask someone to explain the purpose of the temp ArrayList in princec's code example? Setting entities1 = temp right before you .clear() it seems unnecessary, though I'm sure there is a reason for doing so. Is this done to help java's garbage collector?

Thank you,-Bukky

The temp ArrayList is used so that you can switch the references of entities0 and entities1. Then you clear entities1 so you can re-add entities then next time the for loop is executed. It is true you could have just done "entities1 = new ArrayList<Entity>()" but why waste memory?

The temp ArrayList is used so that you can switch the references of entities0 and entities1. Then you clear entities1 so you can re-add entities then next time the for loop is executed. It is true you could have just done "entities1 = new ArrayList<Entity>()" but why waste memory?

why can't you just do this

1 2

entities0 = entities1;entities1.clear();

wouldn't that accomplish the same thing? what am I missing here? WHY AM I SO DUMB

The temp ArrayList is used so that you can switch the references of entities0 and entities1. Then you clear entities1 so you can re-add entities then next time the for loop is executed. It is true you could have just done "entities1 = new ArrayList<Entity>()" but why waste memory?

why can't you just do this

1 2

entities0 = entities1;entities1.clear();

wouldn't that accomplish the same thing? what am I missing here? WHY AM I SO DUMB

You're probably mixing up references and instances. In this case we have two instances of ArrayList. We also have two references, each pointing to one of the ArrayList instances. With your code you'd set both references to point to the same instance, and one of the ArrayList instances will be forever unreachable and garbage collected. Picture yourself holding two apples (instances), one in each hand (reference). How do you switch apples between your hands? You can't hold two apples in one hand, so you'll have to put one apple down on a table (the temp ArrayList reference), then move the other apple to the first hand and finally pick up the first apple from the table with your other hand.

I may have just overcomplicated it a lot, but I hope you understand... xD

Just one side note I would like to make: there is almost no situation in existence, ever, that you would want to use a LinkedList. It exists mostly as a curiosity for computer science degrees as an example of a data structure that has no practical application, like the infamous bubble sorting algorithm.

Cas

Linked lists are the building blocks for structures like B* trees which are your basic database index structure.

This is my Bag implementation, which just extends ArrayList and overrides the remove method. Note that this class only sets indices to null, this is to avoid getting a ConcurrentModificationException while looping through with a for-each loop. After your foreach loop ends, just call remove(null) and all the nulls will removed from the list.

This is my Bag implementation, which just extends ArrayList and overrides the remove method. Note that this class only sets indices to null, this is to avoid getting a ConcurrentModificationException while looping through with a for-each loop. After your foreach loop ends, just call remove(null) and all the nulls will removed from the list.

You're using recursion to remove nulls from the collection. Calling indexOf(null) for every null element in your list adds insult to injury as it will remove the first null element from the list, resulting in moving a lot of (null) elements around in the backing array. Not only is that significantly slower than using iteration, but what if you just removed >10K of items, you'd end up with a StackOverflowError.

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

This is my Bag implementation, which just extends ArrayList and overrides the remove method. Note that this class only sets indices to null, this is to avoid getting a ConcurrentModificationException while looping through with a for-each loop. After your foreach loop ends, just call remove(null) and all the nulls will removed from the list.

You're using recursion to remove nulls from the collection. Not only is that significantly slower than using iteration, but what if you just removed >10K of items, you'd end up with a StackOverflowError.

The bigger question here: why exactly are you removing >10K items?! And how much slower is recursion than iteration?

Wow, this is the BEST thread about lists I've ever read! So many good ideas here!

My 2 cents: I tend to use ArrayList. Their 'sense' of order appeases me.

I'd like to add, for the OP: Whichever you use (Bag, ArrayList, etc.), you probably wont see a noticable difference, until you're working with the big boys on some voluminous project. But I must admit I share your enthusiasm for optimizing

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