77c8520e2e
This concern provides an optimized/simplified version of the "cache_key"
method. This method is about 9 times faster than the default "cache_key"
method.
The produced cache keys _are_ different from the previous ones but this
is worth the performance improvement. To showcase this I set up a
benchmark (using benchmark-ips) that compares FasterCacheKeys#cache_key
with the regular cache_key. The output of this benchmark was:
Calculating -------------------------------------
cache_key 4.825k i/100ms
cache_key_fast 21.723k i/100ms
-------------------------------------------------
cache_key 59.422k (± 7.2%) i/s - 299.150k
cache_key_fast 543.243k (± 9.2%) i/s - 2.694M
Comparison:
cache_key_fast: 543243.4 i/s
cache_key: 59422.0 i/s - 9.14x slower
To see the impact on real code I applied these changes and benchmarked
Issue#referenced_merge_requests. For an issue referencing 10 merge
requests these changes shaved off between 40 and 60 milliseconds.
16 lines
701 B
Ruby
16 lines
701 B
Ruby
module FasterCacheKeys
|
|
# A faster version of Rails' "cache_key" method.
|
|
#
|
|
# Rails' default "cache_key" method uses all kind of complex logic to figure
|
|
# out the cache key. In many cases this complexity and overhead may not be
|
|
# needed.
|
|
#
|
|
# This method does not do any timestamp parsing as this process is quite
|
|
# expensive and not needed when generating cache keys. This method also relies
|
|
# on the table name instead of the cache namespace name as the latter uses
|
|
# complex logic to generate the exact same value (as when using the table
|
|
# name) in 99% of the cases.
|
|
def cache_key
|
|
"#{self.class.table_name}/#{id}-#{read_attribute_before_type_cast(:updated_at)}"
|
|
end
|
|
end
|