summaryrefslogtreecommitdiff
path: root/lib/gitlab/import_export/members_mapper.rb
diff options
context:
space:
mode:
authorRémy Coutable <remy@rymai.me>2016-08-08 15:35:50 +0000
committerRémy Coutable <remy@rymai.me>2016-08-08 15:35:50 +0000
commitfd3a2cf76318a84dc6d3bab9bd9a767c5112106d (patch)
tree9d43fa6355747241fcfcc9309337c47be3337ae8 /lib/gitlab/import_export/members_mapper.rb
parent46e9d8f08db13659fac02e61ef6ce8917bf6a0ac (diff)
parent77c8520e2ecd70520757aed0fbdf434643b60234 (diff)
downloadgitlab-ce-fd3a2cf76318a84dc6d3bab9bd9a767c5112106d.tar.gz
Merge branch 'faster-cache-keys' into 'master'
Optimize "cache_key" using a concern ## What does this MR do? This MR adds a concern (used by Issue and Note) that provides an optimized version of Rails' `cache_key` method. See 77c8520e2ecd70520757aed0fbdf434643b60234 for more details. ## Are there points in the code the reviewer needs to double check? No, though a spell check would be appreciated. ## Why was this MR needed? When loading a lot of data from Redis (e.g. an issue with lots of notes) quite a large amount of time is spent in generating cache keys. This is due to multiple reasons such as: * Rails trying to figure out if it should use `updated_at` or `updated_on` using somewhat inefficient code * Rails relying on pluralization logic to figure out how to generate a cache namespace using a model name * Rails calling a whole bunch of methods in general in the process of generating cache keys In short, Rails is trying to cater to every possible use case, at the cost of performance. ## What are the relevant issue numbers? https://gitlab.com/gitlab-org/gitlab-ce/issues/13651 is not directly related but I ran into this `cache_key` problem when looking into said issue. See merge request !5715
Diffstat (limited to 'lib/gitlab/import_export/members_mapper.rb')
0 files changed, 0 insertions, 0 deletions