pr_ performance

[hadley]

In my heart of hearts I feel like the performance of the pr_ functions is slower than it should be. I don't really have any evidence to base this feeling on, but now that dev profvis defaults to elapsed timing, we now have a way to profile the code and see which API calls are taking up the time.

[jennybc]

My bet is that you are working in a repo that is somehow extreme. Like it has lots of PRs or something.

[hadley]

I think I now understand the basic problem. pr_init() calls github_remotes() twice: once in github_remote_config() and (often) again in git_default_branch(). Because github_remotes() has to hit the GitHub API, it takes around 300ms. The caching in dev gh speeds this up, but it would be nice to eliminate the double call, either by calling github_remotes() and then passing to both functions, or by capturing the default branch info in github_remote_config().

I'm slightly in favour of the second approach, where we always call github_remote_config() before git_default_branch() because then it's clear that git_default_branch() is not responsibility for warning about bad configs.

---

We might still a guaranteed fast (but not correct) version of git_default_branch() that uses default_branch_candidates() for functions like pr_forget(), pr_finish(), and pr_resume() that don't call github_remote_config().