Array fetish?

Miscellaneous Topics
#1

Anyone else here have an array fetish?

I mean I love arrays and I use them everywhere. I use one and two dimensional arrays, sometimes even three, but they are quite ineffective.

I also love recursing through arrays and nothing gives me more pleasure than recursing through two dimensional array.

I even love them so much that I had every single int of one program in an array(not very effective). When programming my game, I try to stay away from this extreme, however I still use them everywhere.

Any other fetishes?

#2

I really like Lists, Iterators, and Maps. Basiclly the whole Collections stuff rocks my world.

#3

Has anyone ever really done a good study on why it is bad to use Collections in a game?

I am very bad at profiling, having not really done it in a real-world sense. If someone tells me how I would go about proving such a thing, I would be happy to actually test this.

Personally, I agree with leknor: I LOVE COLLECTIONS.

HashMap is my b****.

#4

I observerd that as soon as you get used to use HashMaps, you cannot live without anymore.

A former collegue of mine got really HashMap nuts - HashMap(HashMap(HashMap(HashMap)))

not so good in the end…

#5

i tend to mix collections… hashmaps of lists are sweet

i also love java.awt.geom for collision detection… yeah i know it’s not super fast but it’s fast enough. the rendering loop take much more time than all the other stuff (AI, collision detection and all the other stuff)

#6

Isn’t the AWT rendering/mainloop/slacker/window cleaner/thread pooler/worthlesscpu eater invoked and turned on if you even mention the name AWT 2 meters close to the computer.

Last time I remember, calling some of the AWT components invokes the demon, which basically eats up your resources and it requires magic missile +22 to get it back where it came from?

That is if you are not developing with awt…god I’m tired

Hey there is a demon at my house, eating up my resources, called awt. Dog ate my mouse. dog. shit. cd case and parachute I’mgoin

#7

Hey totally understand people falling in love with Collections, i to have formed a more than intimate bond with HashMap.
Sometimes i feel dirty when trying to put collections in collections, like ArrayList.add(ArrayList). Whereas making multilevel int[][][][][] is guilt free.

Being a fellow array lover, im sure you would appreciate their excessive use in this game.
http://www.froggy.com.au/harleyrana/4K-entry.html

Im probally preaching to the converted here, as collection aficionados im sure you know about http://trove4j.sourceforge.net/
Kick arse HashMap implementation, and primitive collections.

To bug you some more with stuff you’ve already seen, a benchmark comparison. http://www.onjava.com/pub/a/onjava/2002/06/12/trove.html

:stuck_out_tongue: :slight_smile:

#8

Protoyping all is good, whatever gets the job done.

In production however,
Arrays, good
Java Collections API, bad

Absolutely, the idea of collections is a Good Thing™, but the standard Java implementation is a memory and performance hog/waster. Profile it anytime with something like OptimizeIT and you will be sick to your stomach.
The amount of under-the-covers “new-ing” is through the roof. Expect a significant amount of GC time cleaning up Java Collections usage.

#9

That trove package looks brilliant- at last ! A guilt free way to use collections!

I have discovered a bit of a thing for classes that have a static member that knows how many of itself exist and can return an appropriate one rather than creating new ones of themselves. I don’t recall if there is a name for them but I use them quite a bit, especially for the web-programming stuff.

#10

Hey Shawn, could you explain where the performance problems are in Collections api. For those of us to cheap to buy a profiler. :slight_smile:

The only direct comparison can be between arrays and ArrayList, which my code is full of. On array list when you don’t use iterators is there much difference between pure arrays?

What are the big performance suckers?

Thanks heaps! :slight_smile:

#11

[quote]could you explain where the performance problems are in Collections api.
[/quote]
The API is a generic API. It’s designed to be acceptable in 95% of the cases. Unfortunatlly with games you spend much of your time in that 5% that isn’t “common”.

[quote]For those of us to cheap to buy a profiler. :slight_smile:
[/quote]
Take a look at the source. I looked at the 1.4.1_02 source for this post.

[quote]The only direct comparison can be between arrays and ArrayList, which my code is full of. On array list when you don’t use iterators is there much difference between pure arrays?
[/quote]
The ArrayList.get(int) and ArrayList.set(int,Object) are pretty close to direct array access. They do an extra range check so the can throw a more friendly ArrayIndexOutOfBoundsException with a meaningful message. They create no garbage.

[quote]What are the big performance suckers?
[/quote]
Most ppl complain about Iterators but by following the code paths for ArrayList Iterators I found no sources of garbage but the level of abstraction that an Iterator provides does incur some overhead that could be advoided if you didn’t need that flexiability.

When people have bad experiences with things, wrongly or rightly, they hold on to those emotions and won’t let go of them without much effort. (Go read the Networking section for examples.) I think in most cases you’ll be fine but there are always people who live in that 5% zone, wrongly or rightly, and complain loudly without qualifying their complaint such that other people can correctly interpet their complaint.

I’m not trying to start a flame way with the above. It’s just my observations. It should be considered “free advice”. (You get what you paid for. :))

#12

Operation and access performance is fine. Of course, it often pays to make your own HashMaps and hashing functions for many cases, as well as getting away from having to make Integers (the Integer class) for int ids that you would like to hash. (Trove does this(

I was mostly talking about performance lost due to extra GC activity.

In our tests, just getting back the iterators everytime we want to do access and traversal (as well as other access, for exmaple getting back copyied sets) shows up high on our object creation profiling, because our run-time code is squeaky clean.

When our own code is clean, and then a outside API shows up high, we start to look elsewhere.