Isometric Tiling and General Object Oriented Woes

Performance/memory is still extremely negligible unless you’re dealing with many hundreds of thousands of elements every frame, or if you’re dealing with a ridiculously huge array.

One common example would be to create a random list of numbers that don’t repeat – i.e. useful for shuffling a playlist iTunes style:

final int COUNT = 1000;
List<Integer> list = ArrayList<Integer>(COUNT);
for (int i=0; i<COUNT; i++) {
    list.add(i);
}
Collections.shuffle(list);

You somehow make it sound as if it’s better to use Arrays over ArrayLists because they’re faster in terms of performance. A very dangerous illusion. It’s like comparing a comfortable car with all kinds of useful gadgets that can go 100 km/h to an old rusty race car that can go 100.000000000000000000000000000000000000000000000000001 km/h.

I agree, but unless the case is trivial you usually should need a very good reason to use a simple Array over an ArrayList. A very good reason might be e.g. “Straightforward” or “I’m lazy” but you might be setting yourself for some refactoring in the future.

In this case where we’re talking about a map it’s perfectly fine to use an Array imo. But I’d fill the Array with ArrayLists to handle objects based on z/depth.

Err…you’re math’s off a bit. The cost of boxing/unboxing (although experimental version of hotspot are working on speed this up) and multiply the memory footprint by a factor of four is really quite significant. Presumably you’re doing a bit more that simply walking this data-structure once per frame. Do most people need to worry about this? nope.

An Integer is a class. So the JVM has to save resources about the Object. (Some info in the accepted answer (Stackoverflow))
So at least (if running a 64-bit JVM) you need 64 bits for the adress of the Integer, and additional 32-bits for the int field inside Integer.
Using int will reduce the memory used, to 32 bits.

That’s not quite correct either. A 64-bit VM will use pointer compression.

In the end there are many different implementations of the jvm. So let’s just say, you need to at least save an additional pointer.

It’s still moot, as I said before. The differences are extremely negligible unless you are working on performance-critical areas – in which case you should have used primitive types in the first place.

The boxing wastes an actually significant amount of space for something as large as a tile map. The JVM will try to reduce things to unboxed form where it can but there’s nothing it can do about the storage.

Now if you have a list of just a few dozen elements, then sure, stop worrying about the overhead.

You guys have taken over this thread and turned it into an argument (multiple arguments actually…)

How bout we stick to addressing the questions that were actually asked and keep the other stuff to their own threads. As a matter of fact, this forum could probably benefit from a comprehensive discussion on Array vs ArrayList and other similar topics. Link to a different thread if you want to start it, otherwise you’re just wasting people’s time who come to this thread for answers pertaining to the original posters questions.

Thank you, that is all

It’s tradition to hijack threads.