possible to have the size limit set by memory size instead of memory items?

[ouvaa]

1. possible to have the size limit set by memory size instead of memory items?
2. possible to fully utilize the memory storage efficiency by it's size? e.g. 1byte takes 1byte + meta info 10 bytes takes 10bytes + meta info etc.

[rockdaboot]

possible to have the size limit set by memory size instead of memory items?

That is possible. The number of items is memsize / (sizeof(key) + sizeof(value) + 32). So for now, you can use this calculation. I'd possibly wait for some upvotes before adding a new API call.

possible to fully utilize the memory storage efficiency by it's size? e.g. 1byte takes 1byte + meta info 10 bytes takes 10bytes + meta info etc

I am not sure that I understand correctly. What exactly is "meta info"?

[ouvaa]

@rockdaboot

1. i understand the calculation but my key size and value is variably defined. it's not consistent 1 length.
2. meta info is the 32 byte overhead of each cache as you have mentioned.

where to do the upvotes to add the api call? thx in advance.

[rockdaboot]

i understand the calculation but my key size and value is variably defined. it's not consistent 1 length.

This sounds you are using any or byte slices or other pointer types as type for keys and values. And if I understand correctly, you want FreeLRU to track the memory pointed to? It sounds like this requires a bigger change in the implementation. Likely there are implementations that do exactly this!?

It would be great if you could come up with a PoC as a base for further discussion (I am still nor sure if we are on the same page).

[ouvaa]

@rockdaboot yes i'm using []byte a lot and you only have "string" because that's the only way to do "comparison"?

anyway, https://github.com/VictoriaMetrics/VictoriaMetrics/blob/master/lib/workingsetcache/cache.go

it's "lru" too

[rockdaboot]

If you want to use []byte as key, you can't do it directly because it does not satisfy the built-in comparable constraint.

You can either convert keys to string, which creates a copy. If you know what you are doing, you can avoid the copy by using unsafe (not recommended). You can also use the hash of your byte slices and use that as key, and make the hash function an identity function. Maybe easiest when using a wrapper around FreeLRU.

Regarding the memory control, you can write a simple wrapper around FreeLRU where you keep track of the amount of memory used by your values. What is missing in FreeLRU for your case is a GetOldest() function ... with that you can effectively reduce the amount of memory in case you overflow.

Does that make sense?