perf: Optimize statCache expiration timestamp by using int64 instead of time.Time#4857
perf: Optimize statCache expiration timestamp by using int64 instead of time.Time#4857vedantdas-source wants to merge 7 commits into
Conversation
There was a problem hiding this comment.
Code Review
This pull request optimizes the entry struct in stat_cache.go by changing the expiration field from time.Time to int64 (using Unix timestamps) and adds a benchmark test suite to measure cache performance. The reviewer suggests using UnixMilli() instead of Unix() across all insertions and lookups to preserve sub-second precision while still maintaining the memory benefits of the int64 representation.
403cdc6 to
67ad8a8
Compare
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #4857 +/- ##
===========================================
+ Coverage 0 83.68% +83.68%
===========================================
Files 0 170 +170
Lines 0 20958 +20958
===========================================
+ Hits 0 17539 +17539
- Misses 0 2762 +2762
- Partials 0 657 +657
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Description
In the
StatCachetheentrystruct tracks TTL expiration using a standard Gotime.Timeobject. Thistime.Timestruct consumes 24 bytes of memory which can be reduced to 8 bytes usingint64for the expiration timestamp. This saves 16 bytes of memory per object.Changes Made
expirationfield in the internal cacheentryfromtime.Timetoint64Insert,InsertImplicitDir,AddNegativeEntry, etc.) now convert the incomingexpiration time.Timeparameter to seconds using.Unix()now.Unix()Benchmarking results
Using
time.Time:Using
int64:All existing tests pass successfully.
Link to the issue in case of a bug fix.
Testing details
stat_cache_benchmark_test.goto measure memory and CPU performance ofStatCacheoperations.Any backward incompatible change? If so, please explain.