The code here is somewhat contrived in favour of the ints. Taking the meat of the | example…

    int a = A | B | G;
    for (int i = 0; i < 1_000_000_000; i++) {
        int b = A | B | G;
        assert a == b;
    }

This is actually compiled as

    int a = 67;
    for (int i = 0; i < 1_000_000_000; i++) {
        int b = 67;
        assert a == b;
    }

The compiler should trivially identify that a == b is always true.

This simple change to the Enum case brings it to within 3x the int scenario…

    Set<Flag> a = EnumSet.of(Flag.A, Flag.B, Flag.G);
    Set<Flag> b = EnumSet.of(Flag.A, Flag.B, Flag.G);
    for (int i = 0; i < 1_000_000_000; i++) {
        assert a.equals(b);
    }

A better range of benchmark cases is required.

Interesting analysis, but the conclusion is a bit contrived. People often prefer type safety over performance. When it doesn’t impact type safety, they still prefer better performance over worse performance. That’s not a contradiction.

You could argue that introducing the EnumSet-type isn’t worth it for that, but I don’t really see a disadvantage from having it.
Those who know about EnumSet, can use it. Those who don’t know it, can continue to use HashSet. And if you don’t know about EnumSet, but find one in a code base, it’s not hard to guess what it does…

Interesting read! Thank you for sharing.

I´ve gained quite a bit of experience with the Java programming language, and very much agree with the accusation that its ecosystem is full of weird choices. Thank you, Mark Rheinhold, I guess. And because of those, other things that got made available got made weird too.

Seeing these benchmarks helps a lot and is quite refreshing: over on Medium, many a content writer regurgitates the same old “tips” without ever providing any benchmarks as proof, thus causing us to believe in fairy tales or continuing traditions for tradition sake, rather than for the benefit of an application.

Thank you for picking an article that includes benchmarks. That is worth repeating.