I realize this is very little of a question and more of a self-planning text, but writing it out and explaining it makes it easier to implement for myself, and I can receive comments. :) I'm currently making a side scroller for my mobile phone, and now I start to have a complete object system working. Currently I use the java.util.Vector class to store my objects; I have one vector for background scenery, one vector for enemies, one vector for friendly bullets, one vector for enemy bullets etc. It has worked quite well until now when I start to load this system with higher quantities of objects. The profiler tells me a significant chunk of time is spent on Vector.elementAt() calls. Essentially, the only operations I do concern the entire set, so I really don't use this method in any other operation than to step through the entire vector at once, and to periodically insert new elements and delete old ones. In C++ I'd have used a std::list or an own linked list for that. Now I figured, perhaps it's very easy to implement one in J2ME? I base this thought on the fact every non-primitive in J2ME seems to be reference, and every object pointed to has a reference counter, causing it to be destroyed when this counter hits zero. The idea: My base object StaticObject would have a member reference called next to another StaticObject. The list would be referenced by a single StaticObject denoting the so-called head or the first object in the list. When inserting a new element it would automatically be at the front; I have no requirements as to be specific about where an object is inserted. The next member of the new head would point to the old head, while the head reference obviously would point at the new object. Deleting an item would merely require setting the next member of the previous object to the next member of the object to be deleted. Now, does anyone has any objections to such a linked list design? To your best guess (I know only profiling can ultimately tell), will this be faster than using the Vector.addElement/removeElement/elementAt combination?

Weird that your profiler should tell you that so long is spent in elementAt(), as it is probably a very trivial function (which may be inlined by the JVM).

I take it this is an on-device profiler for your final device, not a J2SE profiler profiling the app inside a simulator?

My guess is that if elementAt() is really taking that long, you are calling it too often.

I would naively expect a linked list to be slower than a Vector, being as a Vector is likely to contain an array of Object which it simply looks up.

You could re-implement your own ArrayList to see if that works faster, but it seems fairly unlikely unless your vendor has made their own duff implementation of Vector (Which seems unlikely because they probably use Sun's unmodified).

Quote:
I base this thought on the fact every non-primitive in J2ME seems to be reference, and every object pointed to has a reference counter, causing it to be destroyed when this counter hits zero.

No, every non-primitive in *Java* is a reference. This is a core property of the language and has nothing to do with J2ME.

The GC may use reference counting, but it is also capable of freeing unreferenced objects which have a reference count of > 0 (circularly referenced unreachable objects). It does this by being clever.

Mark

Quote:Original post by markr
Weird that your profiler should tell you that so long is spent in elementAt(), as it is probably a very trivial function (which may be inlined by the JVM).

I take it this is an on-device profiler for your final device, not a J2SE profiler profiling the app inside a simulator?

It's the generic WTK emulator actually; I haven't figured out how to use the profiler on Nokia's series 40 emulator yet. I know it's a bit bit dodgy to use it, but it hardly could get better on the cell phone, could it? On the other hand, I suspect most of the total time will be spent drawing graphics either case, but it means there is not much room left for game code. This is why I want to use a linked list if it is more efficient.

Quote:Original post by markr
My guess is that if elementAt() is really taking that long, you are calling it too often.

It depends on how you define "too often". If I mixed the rendering with the update code I could eliminate some of the calls but that would make the code structure horrible. It would maybe also lead to some artifacs due to other entities further down the list not having moved before collision detection on another. In the current system all lists are updated, all lists are checked for removal, all lists are rendered, player is checked versus enemy bullets list, player is checked versus enemy list (it hurts to get rammed), and each player bullet is checked to every enemy. The last check is not even in yet, so it will add even more calls.

However, these lists only represent objects on screen. Objects are spawned in code when the camera passes across a certain position, and they disappear again as soon as they leave screen.

I never do any random access on elements that I suspect an array (vector) would be better at than a list... I'm curious more in detail to why you think the linked list would be slower.

Quote:Original post by markr

Quote:
I base this thought on the fact every non-primitive in J2ME seems to be reference, and every object pointed to has a reference counter, causing it to be destroyed when this counter hits zero.

No, every non-primitive in *Java* is a reference. This is a core property of the language and has nothing to do with J2ME.

I was saying J2ME all the time to avoid any confusion. Yeah I know J2ME = Java in most aspects. I think there may be slight differences in the implementations though; J2ME seems to be more 'lightweight'. I noticed this while looking up conversion functions for some types. I think I saw more in the general Java 2 specification than in the MIDP API.