In general, refcount does not occupy 4 bytes, but LRU bit is too short, which leads to data precision degradation
typedef struct redisObject { unsigned type:4; unsigned encoding:4; unsigned lru:LRU_BITS; / LRU time (relative to global lru_clock) or * LFU data (least significant 8 bits frequency * and most significant 16 bits access time). / int refcount; void *ptr; } robj;
Could you consider making a change to refcount and LRU in a certain version?
Comment From: madolson
I don't think expanding the LRU bits would ultimately change the performance of the algorithm that much. For most use cases, the inefficiency of the LRU comes from the fact it's non-deterministic and uses sampling.
Comment From: jianxinluo
@madolson For the performance of LRU algorithm, your conclusion is completely correct; however, if you need to do some operations through the latest access time of key, there may be unavoidable errors.
1.The accuracy of the object [idletime | freq] command depends on the LRU field. Through the object command, the usage of key can be more accurately counted. 2.Is it necessary for the refcount field to occupy 4 bytes?
Comment From: madolson
@jianxinluo We probably could reduce it, I'm still not sure it provides a significant amount of value to the LRU though. We might just keep it around as extra bits, we won't actually save money because of the jemalloc arena sizes.
Comment From: oranagra
@madolson i actually think adding one or two bits to the LRU can be helpful, i don't think the non-deterministic problem of the LRU mechanism is the only problem. currently we track LRU in milliseconds, but having just 24 bits for it means we wrap around after just 4 hours!
Comment From: huangzhw
@oranagra I remember currently LRU is in seconds.
Comment From: oranagra
@huangzhw you're right... a misleading comment (4 hours indeed seemed a bit shorter than i remembered 8-)
#define LRU_CLOCK_RESOLUTION 1000 /* LRU clock resolution in ms */
return (mstime()/LRU_CLOCK_RESOLUTION) & LRU_CLOCK_MAX;
so 1 second resolution is not ideal for a small db which can replace the entire keyspace in one second. and also the it means the range is about 6 months. so if a portion of the keyspace is stale it can wrap around and appear new (although chances are that it'll get evicted before that).