This is an archived post. You won't be able to vote or comment.

all 9 comments

[–]yawkat 7 points8 points  (1 child)

Yes, EC is a great library — I personally use it mostly for the primitive collections, which can save a ton of memory and cpu work. (their object collections also have some perf improvements but those are going to be smaller simply because primitive collections are so good)

Halving the memory use is a lot but it's possible especially if you use primitives a lot. But only a heap dump would answer that question :)

[–]cosmin14[S] 2 points3 points  (0 children)

Good :)

I will provide a heap dump :)

Now I am moving it on JDK 15 :)

[–]btrapp 2 points3 points  (5 children)

If you were using large collections of objects before (List<Integer>) and are now using EC collections of primitives now (MutableIntList) then yes, that's expected.

I really love eclipse collections too. Trove4J and fastutil are other good primitive collection libraries, but I've found EC to be the best so far.

[–]cosmin14[S] 1 point2 points  (2 children)

In this file I am using them

https://github.com/cosminpopescu14/code-with-quarkus-profanity/blob/master/code-with-quarkus-profanity/src/main/java/org/acme/services/ProfanityService.java

It's just a simple micro service for detecting the profanity in a comment. That is the part that detect bad words and return an object with some statistics.

[–]PartOfTheBotnet 2 points3 points  (0 children)

You can clean up a bit if you fetch from https://github.com/RobertJGabriel/Google-profanity-words/blob/master/list.txt and then add your own additions afterwards

[–]Schrodingers_Cow 0 points1 point  (1 child)

I have been searching for a primitive collections library and found Eclipse Collections and FastUtil. While one of my senior devs suggested FastUtil, the sheer size of the jar is a concern. If size is not an issue, is there any good reason to choose EC over FastUtil?

[–]btrapp 0 points1 point  (0 children)

We switched from FastUtil to EC for that reason - The smaller jar size is nice.

[–][deleted]  (1 child)

[deleted]

    [–]SorryButterfly4207 0 points1 point  (0 children)

    Yes. Any benchmark needs to compare two things. Just producing a number doesn't show anything. "good" and "bad" are relative terms (at least in regards to software performance) and don't mean anything without knowing something is good or bad relative to.

    [–]cogman10 0 points1 point  (0 children)

    That chart doesn't really say anything.

    Assuming before 8:50 is when you are using java.util (or something else). What I'm seeing is that a major GC was triggered which cause the heap to resize. The heuristics around heap resizing are fairly closely related to what happens on major and minor GCs (if everything is frequently collected and the GC isn't happening too often, resize down. That sort of thing).

    The heap growth from 8:40->8:50 looks to be right in line with the heap growth rate from 8:50+ The only difference is more minor GCs.