38% time: MergeRequest#can_be_reverted?: This is actually called twice: once for the the revert_in_fork_path field, and once for can_revert_on_current_merge_request field. We search all notes to look for a message that says "This reverts commit X" or "This reverts merge request Y"
18% time: MergeRequest#has_ci?: we have to retrieve all pipelines and related commit SHAs to determine this
11% time: MergeRequest#merge_commit_message: we have to extract all "Closed by" issues to create this message
It seems to me that the revert check seems unnecessarily expensive and could be cached more effectively, and a lot of these fields aren't really necessary just to display the merge request.
The JSON response is just for the MR widget, it doesn't block the initial page load, and it's not used for commenting (really, this is very easy to test!). It shows up several times because we poll for the widget response.
The endpoint we use for commenting is /notes, so I'm pretty confused about the exact source of the issue here.
@fatihacet@jschatz1 : Can/should we do this one regardless of the Vue refactor #38178 (closed)? I.e. we can work on this one first (or in parallel) and get some performance improvements first right?
@victorwu I think that's something doable. As we already discussing in this issue about refactoring the MR discussions would take 2-3 months, it makes sense to improve performance of what we have right now. We should make an investigation to find out in which places we can make improvements.