The following discussion from !74058 should be addressed: - [ ] @reprazent started a [discussion](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/74058#note_728047445): > https://log.gprd.gitlab.net/goto/39e6fe9029e7a211a15825d4b4456485 > > This endpoint seems to be slow because it's loading all branches and tags from the repository to count how many refs would be protected: https://gitlab.com/gitlab-org/gitlab/blob/636f2ca5ba3769719dc865a01f9445f89fcf0ff9/app/controllers/projects/settings/repository_controller.rb#L83 > > The logs confirm this: https://log.gprd.gitlab.net/goto/3d79f6c48e6c74f89dbc505879ad7123 > > The `cpu_s` there seems to be iterating the branches & tags and matching regexes. > > Though the endpoint is not super busy, so we could tolerate this low urgency for now, but what do you think about improving the performance by limiting the number of refs we're matching and display a 99+ kind of value. > > But I think there might be a bug here, we're doing all this counting, for protected branches and tags, but then we're only showing this number (which I think would be 0) if `@protected_branches` would be empty: https://gitlab.com/gitlab-org/gitlab/blob/636f2ca5ba3769719dc865a01f9445f89fcf0ff9/app/views/projects/protected_branches/shared/_branches_list.html.haml#L4 > > Do you think this is worth looking into before we lower the urgency?