'current_time' vs live time checks and edge cases

[dormando]

the current_time variable is a monotonic counter that's updated once per second via a libevent timed event. It was added to avoid overhead of fetching the clock, especially on systems where that function is slow (not typically linux).

It's probably worth re-evaluating this, at least subtly.

1. Benchmark under high thread load with current_time's most frequent usages replaced with a direct clock call. Is current_time a bottleneck on some systems due to false sharing/etc? Is that the same with the system clock?
2. What systems still exist which have a slow clock? Any of the BSD's? Mac?
3. For cases where SET'ing a 1s TTL, the expiration time can be anywhere from immediate to nearly two seconds. Is the overhead of a clock call low enough that we can check the "time since the last time current_time was updated" during a SET and increment the TTL where it makes sense? Ensuring an item will last for 1-2 seconds rather than 0-2 seconds (or 1-3 seconds if blindly incrementing).

Might be a fun task for a student or contributor. Make sure you use mc-crusher to really get the request rate high.

[dormando]

#307 - was reported here years ago. users do actually run into this.