Git: Speed up displaying branches in Select Revision dialog from Cherry pick#9305
Git: Speed up displaying branches in Select Revision dialog from Cherry pick#9305OndroMih wants to merge 1 commit into
Conversation
…ry pick Defer branch merge status computation in Select Revision dialog When the Select Revision dialog is opened from Cherry Pick, the branchMergeWith field is set, causing getCommonAncestor() to be called for every branch (120+) before nodes are shown. This blocks the single-threaded RepositoryPanel RequestProcessor for ~10 seconds. Move the getCommonAncestor loop out of refreshBranches() into a separate background task (computeMergeStatuses) that runs after nodes are already displayed. Nodes initially show with null merge status and are updated incrementally as results arrive via updateBranchMergeStatus/ updateMergeStatus. When a branch node is selected and its merge status is still pending, trigger an immediate single-branch lookup.
mbien
added
git
matthiasblaesing
left a comment
matthiasblaesing
left a comment
There was a problem hiding this comment.
I think this is an improvement.
I tested though with the NetBeans repository, with all PR branches, where cherrypick is still problematic (first dialog show takes ages to update merge statuses, second opening does not show any branches). But that does not need to be addressed now.
I left a few inline comments.
| // Walk up to BranchesTopChildren via parent chain | ||
| Node parent = branchNode.getParentNode(); | ||
| if (parent != null) { | ||
| parent = parent.getParentNode(); | ||
| } |
There was a problem hiding this comment.
Shouldn't this be a loop? Else you only go one level up.
| revisionsPanel1.updateHistory(currRepository, roots, currRevision); | ||
| } | ||
| // If a branch node with pending merge status is selected, compute it immediately. | ||
| computeMergeStatusForSelectedNodeIfNotComputedYet(); |
There was a problem hiding this comment.
This does not work for me. If I see it correctly in may case (git checkout of netbeans with all PR branches) the RequestProcessor RP has a throughput of 1 and that one place is blocked by the initial merge status determination (computeMergeStatuses).
| java.util.Map<String, String> single = new HashMap<String, String>(); | ||
| single.put(branchName, info.branch.getId()); |
|
Thanks for reviewing, @matthiasblaesing , your comments make sense. When I get to it, I'll review the code once again, I see some potential improvements and cleanup even beyond what you commented. |
3 participants
Defer branch merge status computation in Select Revision dialog
When the Select Revision dialog is opened from Cherry Pick, the branchMergeWith field is set, causing getCommonAncestor() to be called for every branch (120+) before nodes are shown. This blocks the single-threaded RepositoryPanel RequestProcessor for ~10 seconds.
Move the getCommonAncestor loop out of refreshBranches() into a separate background task (computeMergeStatuses) that runs after nodes are already displayed. Nodes initially show with null merge status and are updated incrementally as results arrive via updateBranchMergeStatus/ updateMergeStatus. When a branch node is selected and its merge status is still pending, trigger an immediate single-branch lookup.
To test:
On Netbeans repository, select Cherry Pick dialog, then click Select Revision.
Old behavior: It takes a few seconds until the branches and tags are displayed (because the merge status is being computed)
New behavior: Branches and tags are displayed immediately, with [merge ? ] behind the name, merge status is computed in the background, and then [merge ? ] is either removed (not merged) or replaced with [merged].
PR approval and merge checklist:
If this PR targets the delivery branch: don't merge. (full wiki article)