Header Search - Fix GitLab loading time by removing search_context usage
What does this MR do and why?
Closes #378413 (closed)
Right now the Header Search component is significantly increasing .Com load time by nearly 20% (50ms - 150ms depending on page).
After a deep dive with @mkozono it appears there is something very inefficient happening inside of SearchContext. I am not entirely sure what is so inefficient about it but it is killing our render time.
After exploring what SearchContext is used for with the header_search it was discovered we could instead un-abstract the logic inside of the Builder method in SearchContext into the helper method that was parsing the SearchContext. By doing this we completely remove the need for the SearchContext class (in this context) at all. Instead utilizing the conditional existence of @instance methods set by the respected controllers we are able to significantly reduce the render time.
Screenshots or screen recordings
GDK
| Before | After | |
|---|---|---|
| Screenshot |  |
 |
| Description | 70.51ms (8.8%) | 10.24ms (0.68%) |
Review App
| Before | After | |
|---|---|---|
| Screenshot |  |
 |
| Description | 110.51 ms (22% of render time) | 9.58ms (2.8% of render time) |
How to set up and validate locally
Testing Performance
- Open teh Flamegraph in Wall mode on a Group or Project
- CMD+F for
header_search - Ensure the render time appears reasonable (less than 5% of total time at least)
- Additionally compare to
masterto visualize the speed increase
Testing existing functionality
- Go to a Project/Group
- Search via the header search
- Ensure things like the group, project, tab are all preserved when you search (similar to production)
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.