Investigate and improve git blame performance for files with extensive commit history

Summary

When fetching blame information for large files with extensive commit history, the git blame command is slow even when limiting the line range. This affects the inline blame viewer experience in the blob page.

Context

See &11471 (comment 3012821025)

I'm pretty sure we discussed this at some point but couldn't find the thread: I noticed loading the blame information is slow for large files, even after we implemented the API limit (#393764 (comment 1721192274) / https://gitlab.com/gitlab-org/gitlab/-/work_items/425270).

Is there a way for us to see where the bottleneck is?

In this example on staging I requested the first 70 lines of blame info for this file and the request took around 8 second

I've found logs for this request. Most of the time is spent in Gitaly.

Screenshot_2026-01-16_at_18.04.12

Screenshot_2026-01-16_at_18.05.00

RawBlame is slow to respond. Either the Rails client isn't correctly providing limits (unlikely) or Gitaly struggles to fetch blame data from the repository.

For testing, you can clone the repository locally and run git blame <file_path> in the console. If Git cli also takes seconds to respond, then we're likely facing an issue with large Git repositories. That might need assistance from the Gitaly team since we're hitting Git limitations.

Local testing confirms the issue

(Tested using https://staging.gitlab.com/jerasmus/linux/-/blob/master/MAINTAINERS?ref_type=heads)

Running git blame -L 1,70 MAINTAINERS locally also takes approximately the same amount of time (~8 seconds), confirming this is a Git-level performance limitation rather than an API or application issue.

Problem

  • git blame with line range limits (-L 1,70) still takes several seconds for large files with extensive commit history
  • This creates a poor user experience for the inline blame viewer feature
  • The bottleneck appears to be at the Git/Gitaly level

Related issues

Edited by Jacques Erasmus