trove vs jdk collections

[Janny]

It looks like trove is not that fast as modern jdk collections with boxing and unboxing. tried multiple times on my home pc with add/remove/lookup operations, trove 2 times slower. is something wrong with my test environment? used LongObjectHashMaps with lots of elements.

[Aleksey Shipilev]

We've seen this before, and in our case it was explained by Trove doing
the prime-sized hash tables, that required hardware division to compute
the bucket, and JDK collections using 2^k-sized hash tables, that allow
computing modulo by masking.

But of course, it's hard to say for sure until you publish your code and
your analysis.

-Aleksey.

> --
> You received this message because you are subscribed to the Google
> Groups "mechanical-sympathy" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to mechanical-symp...@googlegroups.com
> <mailto:mechanical-symp...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout.

[Roman Leventov]

Janny, Trove is dead. Choose

- Fastutil for best perf in not primitive-to-primitive case

- Koloboke in primitive-to-primitive case

- GS collections if you also want to have pretty performant lambda-style framework on top, and wide range of implementations

- also HPPC-RT looks interesting, not yet clear how much performant compared to others

See http://java.dzone.com/articles/time-memory-tradeoff-example and http://java-performance.info/hashmap-overview-jdk-fastutil-goldman-sachs-hppc-koloboke-trove-january-2015/

In general, this is insane situation that a lot of people do duplicate work... See https://groups.google.com/forum/#!topic/fastutil/eyBRd87sqCk

On 8 February 2015 at 13:41, Janny <winnie...@gmail.com> wrote:

It looks like trove is not that fast as modern jdk collections with boxing and unboxing. tried multiple times on my home pc with add/remove/lookup operations, trove 2 times slower. is something wrong with my test environment? used LongObjectHashMaps with lots of elements.

--

You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group.

To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-symp...@googlegroups.com.

[pja...@gmail.com]

Hello!

I’ve developed a Java parallel collections library (PJC) that improves the performance of the Java Collections. At this moment, thery are only implemented ArrayList and HashMap, and HashSet is being implemented.

You can download the source code and the benchmarks to probe Java, PJC, Trove and GoldmanSachs Collections here: https://forxa.mancomun.org/frs/?group_id=381

The documentation (at this moment, only in Spanish, but the graphics are easily understood) is available here: https://forxa.mancomun.org/docman/?group_id=381 . There, you can see the results of the execution of the benchmarks.

The project has also been uploaded to GitHub: https://github.com/mariaacha/PJC

If someone has any question, doubt or suggestion, can contact with me by email: PJa...@gmail.com

[Jonathan Yu]

Interesting work, thanks for sharing!

In the memory tests, you're using Runtime#freeMemory and Runtime#totalMemory -- would something like Aleksey's JOL library provide more accurate results? Were you using Aleksey's other library, JMH, to do the performance tests?

Tests also conventionally use a harness like JUnit or TestNG. It'll make them easier for others to run (especially as part of a CI process).

You might also want to look through the Java Language Spec's coding style, as it describes the idiomatic way to write Java code.

Cheers,

Jonathan

--

You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-symp...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Jonathan Yu / @jawnsy on LinkedIn, Twitter, GitHub, Facebook

“Ever tried. Ever failed. No matter. Try again. Fail again. Fail better.” — Samuel Beckett, Worstward Ho (1983) 

“In an adaptive environment, winning comes from adapting to change by continuously experimenting and identifying new options more quickly and economically than others. The classical strategist's mantra of sustainable competitive advantage becomes one of serial temporary advantage.” — Navigating the Dozens of Different Strategy Options (HBR)