Hash table performance
in [Java Programming]
|
Prev: The future of Java
Next: weird issue with new lines
From: Jon Harrop on 22 Nov 2009 14:43 Marcin Rzeźnicki wrote: > Yeah, I see. Well, what VM did Jon use? That might be crucial to know > what happened. $ java -version java version "1.6.0_13" Java(TM) SE Runtime Environment (build 1.6.0_13-b03) Java HotSpot(TM) Server VM (build 11.3-b02, mixed mode) -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?u
From: Marcin Rzeźnicki on 22 Nov 2009 14:02 On 22 Lis, 20:43, Jon Harrop <j...(a)ffconsultancy.com> wrote: > Marcin Rzeźnicki wrote: > > Yeah, I see. Well, what VM did Jon use? That might be crucial to know > > what happened. > > $ java -version > java version "1.6.0_13" > Java(TM) SE Runtime Environment (build 1.6.0_13-b03) > Java HotSpot(TM) Server VM (build 11.3-b02, mixed mode) > Quite recent. And were your measurements affected by using HashMap instead?
From: Martin Gregorie on 22 Nov 2009 14:38 On Sun, 22 Nov 2009 11:02:14 -0800, Marcin Rzeźnicki wrote: > On 22 Lis, 20:43, Jon Harrop <j...(a)ffconsultancy.com> wrote: >> Marcin Rzeźnicki wrote: >> > Yeah, I see. Well, what VM did Jon use? That might be crucial to know >> > what happened. >> >> $ java -version >> java version "1.6.0_13" >> Java(TM) SE Runtime Environment (build 1.6.0_13-b03) Java HotSpot(TM) >> Server VM (build 11.3-b02, mixed mode) >> >> > Quite recent. And were your measurements affected by using HashMap > instead? > Did you try setting the initial capacity to 1000? I've had terrible performance from C programs that malloced for every one of a huge number of little items it wanted to put on the heap. I'd hope any JVM was better than that but you never know.... Besides, its quite possible NET allocates bigger chunks since Windows memory allocation was/ is quite slow. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
From: Patricia Shanahan on 22 Nov 2009 14:47 Jon Harrop wrote: > Marcin Rzeźnicki wrote: >> Yeah, I see. Well, what VM did Jon use? That might be crucial to know >> what happened. > > $ java -version > java version "1.6.0_13" > Java(TM) SE Runtime Environment (build 1.6.0_13-b03) > Java HotSpot(TM) Server VM (build 11.3-b02, mixed mode) > It might help to show your .NET program as well. If people ran both it and the Java version on a few different systems, we could see how much, if any, of the performance difference is configuration-specific. Patricia
From: Lew on 22 Nov 2009 15:54
Tom Anderson wrote: >> I'd be *very* surprised if that was true. In this simple program, escape >> analysis could eliminate the locking entirely - and current versions of >> JDK 1.6 do escape analysis. The OP is not using a current version of Java 6. Jon Harrop wrote: >> $ java -version >> java version "1.6.0_13" >> Java(TM) SE Runtime Environment (build 1.6.0_13-b03) >> Java HotSpot(TM) Server VM (build 11.3-b02, mixed mode) According to <http://java.sun.com/javase/6/webnotes/6u14.html> > Optionally available are two new features - > escape analysis and compressed object pointers. Which implies strongly that escape analysis, being "new" in 6u14, was not available in 6u13. Even then, as Marcin Rzeźnicki wrote: > ... escape analysis is turned off by default. .... > Well, I am more inclined to believe that his VM somehow did not > perform lock optimization. -- Lew |