1. What are you trying to do?

Currently ImmutableSet fixes a 0.7 load factor and will auto shrink the table size.

In one of our recent use case, this results in a 2~4 collision rate which increased the set look up cost about 50%~100%, compared with 0.35 or a lower load factor. It's constant level increase but our service is latency sensitive so there is still some optimization space.

2. What's the best code you can write to accomplish that without the new feature?

We could use the JDK HashSet: HashSet(size, customLoadFactor).

We could also 'hack' by setting x2 times size using ImmutableSet.builderWithExpectedSize(2*size), which will result in 0.35 load factor but seems to be a bug not triggering auto shrink.

3. What would that same code look like if we added your feature?

Something like: ImmutableSet.builderWithLoadFactor(0.2f)

(Optional) What would the method signatures for your feature look like?

Concrete Use Cases

We try to look up String objects a few thousand times in a Set with about 1k size, where most look up shall return false result.

The hardcoded 0.7 load factor results in a 2~4 collision rate, increasing the set look up cost about 50%~100%, compared with 0.35 or a lower load factor. We do a few thousand times check so get a ~0.05ms latency increase, which can still be improved by many approaches and reducing load factor (space for time) is one of the easiest options.

(JDK HashSet also works but the structure is less compact and efficient as ImmutableSet, making ImmutableSet with custom load factor API an ideal solution for us)

Packages

No response

Checklist

• I agree to follow the code of conduct.

• I have read and understood the contribution guidelines.

• I have read and understood Guava's philosophy, and I strongly believe that this proposal aligns with it.

• I have visited the idea graveyard, and did not see anything similar to this idea.