BigW Consortium Gitlab
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.
Name |
Last commit
|
Last update |
---|---|---|
.. | ||
access_requestable_spec.rb | Loading commit data... | |
awardable_spec.rb | Loading commit data... | |
case_sensitivity_spec.rb | Loading commit data... | |
faster_cache_keys_spec.rb | Loading commit data... | |
issuable_spec.rb | Loading commit data... | |
mentionable_spec.rb | Loading commit data... | |
milestoneish_spec.rb | Loading commit data... | |
participable_spec.rb | Loading commit data... | |
statuseable_spec.rb | Loading commit data... | |
strip_attribute_spec.rb | Loading commit data... | |
subscribable_spec.rb | Loading commit data... | |
token_authenticatable_spec.rb | Loading commit data... |