Ok, the title is a little misleading, because there isn’t a problem with it 
I’m interested in doing the same sort of thing for HashMap, but before I go through the effort. Have you already done this?
This is obviously a question for @pspeed
@t0neg0d said: Ok, the title is a little misleading, because there isn't a problem with it ;)I’m interested in doing the same sort of thing for HashMap, but before I go through the effort. Have you already done this?
This is obviously a question for @pspeed
What is your goal for doing this to HashMap? SafeArrayList had a few goals so I’m not sure which one you are zeroing in on.
@pspeed said: What is your goal for doing this to HashMap? SafeArrayList had a few goals so I'm not sure which one you are zeroing in on.
I considered this after posting…
I have a situation where I’m changing the hashmap very infrequently, but iterating often.
Curious: how big is the hashmap?
Anyway, there is no built in class for this. JME doesn’t iterate over plain hashmaps very often. Do you need to iterate over the Map.Entry objects or just the values?
Might I ask for the reason in this case? As I loop over a few dozen hashmaps every frame I cannot really feel any performance problems.
@pspeed said: Curious: how big is the hashmap?Anyway, there is no built in class for this. JME doesn’t iterate over plain hashmaps very often. Do you need to iterate over the Map.Entry objects or just the values?
Just the values… I guess I could dump it to an array and just update the array on a change to the hashmap.
@Empire Phoenix said: Might I ask for the reason in this case? As I loop over a few dozen hashmaps every frame I cannot really feel any performance problems.
This was my next question… it would have to improve performance on some level, depending on the number of the map values stored, etc.
SafeArrayList was written for two reasons:
-
it avoids creating an iterator just to iterate over the list since you can get at the raw array. These lists are accessed a lot and Iterators were avoided to bad effect because…
-
this list implementation allows items to be removed during iteration because the iterator is working on a snapshot copy. The old for(int i=0…) version of these loops tried a couple ineffective tricks to allow things like children and controls to be able to remove themselves. Now it’s not an issue.
The fact that for(item : array) loops are a bit faster than for(int i=0) { list.geti) } loops is just a bonus.
@t0neg0d said: This was my next question... it would have to improve performance on some level, depending on the number of the map values stored, etc.
But what is the issue with plain HashMap performance? Are you worried about creating Iterator object or about speed of iteration with having to skip empty bucket slots sometimes? During profiling, how bit percentage of garbage is generated from that iterator/how much cpu is taken on iteration itself?
the thing i know is that you can have a pretty nice performance boost when you use treemap/treeset, but for this you need to have comparable elements (and this means that you’ll not modify these elements in their attribute involved in the comparison).
And you can have non-comparable element and implements the comparator interface. But i think you already know all of this.
EDIT : and you can iterate and remove values in a map during this iteration. See the “entrySet()” method of the map, it’s explicitly said that it’s backed with the map, so you can call remove. Same things for “keys”
Alternativly if its just to avoid concurrentmodification exceptions,
a ConcurrentHashMap might do the trick.