Parse affected ranges only once per affected package scan
What does this MR do and why?
Previously, the version range matchers used by vulnerability scanning
always constructed a new affected range when calling the affected?
method. If called sparingly, the performance of the method can be seen
as acceptable, but if done continuously - in a loop for example - then
the performance of the matcher begins to suffer. To address this, the
matcher class now initializes the affected range only once at the
beginning, and re-uses the same instance for future comparisons. This
means that we improve the memory footprint significantly when it's
called in loops as is the case with Continous Vulnerability Scanning
where we've seen allocations in the realm of GiB. By proxy, this
improves the performance of the Sidekiq instance that CVS runs on
because the garbage collector does not need to prune as many unreachable
objects in memory.
MR acceptance checklist
Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.
Screenshots or screen recordings
Screenshots are required for UI changes, and strongly recommended for all other merge requests.
| Before | After |
|---|---|
How to set up and validate locally
This MR depends on Cleanup version comparison functions (gitlab-org/ruby/gems/semver_dialects!99 - merged). Until that MR is merged and released, you can test the changes by doing the following in the checked out branch.
bundle remove semver_dialects
bundle add semver_dialects --git https://gitlab.com/gitlab-org/ruby/gems/semver_dialects --ref 'otovar/refactor-os-comparisons'
bin/rspec -fd ee/spec/lib/gitlab/vulnerability_scanning/