Why LFUCache doesnot initialize with a loadFactor=1.0f of a Hashmap?

[wnjustdoit]

Why LFUCache doesnot initialize with a loadFactor=1.0f of a Hashmap?

[igr]

Just wondering: why to go with the 1.0f factor? This way we are using the DEFAULT_LOAD_FACTOR of 0.75f.

[wnjustdoit]

The same to jodd.cache.FIFOCache and jodd.cache.LRUCache. If loadFactor less than 1.0f, It leads to additional capacity expansion when the capacity can't be fully utilized.

[neroux]

If loadFactor less than 1.0f, It leads to additional capacity expansion when the capacity can't be fully utilized.

As it does when it exceeds 1.0f.

There is a reason why Sun decided to go with 0.75f

As a general rule, the default load factor (.75) offers a good tradeoff between time and space costs. Higher values decrease the space overhead but increase the lookup cost (reflected in most of the operations of the HashMap class, including get and put).

[wnjustdoit]

Perhaps you didn't recognize my real problem. When Map is initialized, its capacity is fixed, then this does not matter with any space costs.
cacheMap = new HashMap<>(maxSize + 1, 1.0f); This makes no costs later after it's be initialized. Right?

[neroux]

I am not sure what you mean by "fixed". That is the initial capacity.

Can you elaborate how Sun was wrong with their standard approach?

[wnjustdoit]

Not Sun's problem. Maybe my English is poor..

[neroux]

Well, you are saying that Sun's default value is an issue.

[wnjustdoit]

Not yet. Waiting for another one to answer my question...

[igr]

I believe that since we should not allow more then maxSize elements, the Map internal size should be limited to this number as well. Otherwise, once when we reach 75% the HashMap will grow, but we can use only remaining 25%, and not the rest.

[neroux]

Not yet? That is what you have been saying and it would be good to know why you disagree with Sun.

@igr, I am not sure I quite follow.

[igr]

Sorry @neroux didn't explain myself.

So what is going on here is that we don't need any factor, as we have initial size that never gets resized.

What @wnjustdoit says is that he assumes that initial size is less then maxSize. In such case he would be correct: if e.g. maxSize is 100, and initial size is 60, when we add element 61, the internal size would grow > 100.

@wnjustdoit since we are setting the initial seize to be max+1, the internal resize would never happened. agree?:)

[neroux]

Thanks for the summary, @igr. Yeah, that should never be an issue in the first place and to be fair, even 0.75f shouldn't be an issue.

Again, Sun's stance on that :)

As a general rule, the default load factor (.75) offers a good tradeoff between time and space costs. Higher values decrease the space overhead but increase the lookup cost (reflected in most of the operations of the HashMap class, including get and put).

[wnjustdoit]

@igr So what's the conclusion?

[igr]

Since it is not really an issue, this should be closed @wnjustdoit ... let me know if I am missing something :)