This week's book giveaway is in the Jython/Python forum.
We're giving away four copies of Murach's Python Programming and have Michael Urban and Joel Murach on-line!
See this thread for details.
Win a copy of Murach's Python Programming this week in the Jython/Python forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

TreeMap & HashMap vs javolution.FastMap  RSS feed

 
Predrag Stojadinovic
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi guys,

I've seen the topic about TreeMap vs HashMap but I am more interested in the javolution.FastMap

Can anyone comment on if and why javolution.FastMap is better than HashMap and TreeMap?

THANKS!
 
Jeanne Boyarsky
author & internet detective
Sheriff
Posts: 36430
454
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Predrag Stojadinovic:
Can anyone comment on if and why javolution.FastMap is better than HashMap and TreeMap?

"Better" is a relative term. Different things tend to be better in different scenarios.

FastMap is meant for real-time systems where the goal is to have constant time access. For example, suppose you start with an Map of 10 elements and add a million more elements. The Java built-ins will sometimes insert right away and sometimes re-size the underlying map. (Maybe add more hash buckets or normalize the tree.) A real-time map will increase capacity in a constant fashion (maybe by having each caller copy one thing.)

For a real-time system, FastMap is clearly better. For other systems, it depends what the criteria are. FastMap is hightly likely to use more memory than the Java built-in. Whether this is better or worse dpends on the scenario.
 
Billy Tsai
Ranch Hand
Posts: 1306
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you are using Java 5 or higher, you should use the new java.util.concurrent package for improved performance, like the ConcurrentHashMap in this case is threadsafe and at the same time safely permits any number of concurrent reads as well as tunable number of concurrent writes.
 
Mike Simmons
Ranch Hand
Posts: 3090
14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you read the FastMap API linked above, it does claim some advantages over ConcurrentHashMap, not just regular HashMap. Specifically it claims constant-time access, which is primarily of interest for real-time systems, as Jeanne said. Also I note that it says: "Retrieval reflects the map state not older than the last time the accessing thread has been synchronized" In other words if you don't synchronize, you can see old data. I don't think this is possible for ConcurrentHashMap, which means that there may be a tradeoff here - FastMap may be faster than CHM, at a cost of allowing old data to be visible. For some applications that may well be a good trade-off to make.

Note: I'm just speculating based on what the API says. If you need reliable data on this, the best way is to test it yourself for the way you're using the map in your application.
 
Pat Farrell
Rancher
Posts: 4678
7
Linux Mac OS X VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
More importantly, this smells of premature optimization.

What does your application need from a functional point? What are your requirements? Implement that. If its slow, change out the slow stuff.
 
Mikko Kohtamäki
Ranch Hand
Posts: 112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Simple questions to specify, do you need synchronization?

And you can test speed of these put and get methods in your code.
 
Predrag Stojadinovic
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Pat Farrell wrote:More importantly, this smells of premature optimization.
I would have to disagree. If I am getting ConcurentModificationException with HashMap and I eliminate this exception simply by using FastMap instead than it can not be called premature optimization, right?
 
luri ron
Ranch Hand
Posts: 87
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
JDK's ConcrurentHashMap doesn't throw conncurrentmodificationexception either. it depends on the volume and latency requirement of your application. i myself haven't see any performance issue for app using ConcurrentHashMap.
 
Ernest Friedman-Hill
author and iconoclast
Sheriff
Posts: 24215
37
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Predrag Stojadinovic wrote:
Pat Farrell wrote:More importantly, this smells of premature optimization.
I would have to disagree. If I am getting ConcurentModificationException with HashMap and I eliminate this exception simply by using FastMap instead than it can not be called premature optimization, right?


It may be, yes, if there are several other alternatives (ConcurrentHashMap being only one of the possibilities in the pure JDK without dragging in third-party libraries.)
 
Predrag Stojadinovic
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ernest Friedman-Hill wrote:It may be, yes, if there are several other alternatives (ConcurrentHashMap being only one of the possibilities in the pure JDK without dragging in third-party libraries.)
But, if we believe this quote found in the Javolution API: "Unlike ConcurrentHashMap, access never blocks" then I must conclude this to not be a premature optimization.

Don't get me wrong, I understand premature optimization and I agree completely that it should be avoided, but to be completely fair, this does seem more like removing bugs than just optimization.
 
Mike Simmons
Ranch Hand
Posts: 3090
14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, but that's just one aspect of comparison between the two. We've discussed several others as well. Is blocking actually a problem in your current program? And are the other points relevant for you? Note that CHM doesn't block indefinitely - it just may block a short while, whereas FM doesn't. At a cost of maybe providing old data.

Also, if you were getting ConcurrentModificationException, that's really more of a programming error than a performance optimization. Fixing such a problem is hardly premature either, since you were actually experiencing a problem. But that's new information, beyond your original post. Pat's post was based on what you'd told us at the time.

Anyway, glad it seems to be working for you.
 
Ernest Friedman-Hill
author and iconoclast
Sheriff
Posts: 24215
37
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Javolution seems to be one of those technologies that everyone agrees sounds great, but nobody uses for some reason. Maybe this will change someday.
 
Predrag Stojadinovic
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Mike Simmons wrote:...
Completely agree! Thanks all of you guys for your time and input!
 
Consider Paul's rocket mass heater.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!