Community
Participate
Working Groups
For repositories with many branches opening any subclass of AbstractBranchSelectionDialog can take a few seconds. (I experienced about 8s). During this time the complete UI is frozen. Therefore this dialog should open and then asynchronously load the refs to display.
8 sec is a very long time for loading branches. How many branches does your repository have ? Do you run gc on your repositories ?
(In reply to Matthias Sohn from comment #1) > How many branches does your repository have ? ~8000 - 9000, depends on current work load > Do you run gc on your repositories ? I believe I've seen this independently if gc was invoked or not recently. Actually I avoid opening branch selection dialog due this freeze as much as I can (I don't need it often).
(In reply to Andrey Loskutov from comment #2) > (In reply to Matthias Sohn from comment #1) > > How many branches does your repository have ? > ~8000 - 9000, depends on current work load Why do you use so many branches ? Mostly remote tracking branches or local branches ? > > Do you run gc on your repositories ? > > I believe I've seen this independently if gc was invoked or not recently. > Actually I avoid opening branch selection dialog due this freeze as much as > I can (I don't need it often). How about profiling this to learn where so much time is spent ? Moving loading branches to the background is for sure a good idea but 8 seconds is still long when it happens in the background.
(In reply to Matthias Sohn from comment #3) > (In reply to Andrey Loskutov from comment #2) > > (In reply to Matthias Sohn from comment #1) > > > How many branches does your repository have ? > > ~8000 - 9000, depends on current work load > > Why do you use so many branches ? > Mostly remote tracking branches or local branches ? Remote tracking, I believe it is due many developers (~100?), many releases (3 supported in parallel at least), lot of various "project" branches under "master", lot of temporary bitbucket branches for code reviews, bug fixes etc. @Tim: we should do some research where/why do we create most of the branches, just in case we have some tooling issue. > How about profiling this to learn where so much time is spent ? I believe it is due the repo size on disk (~15 GB). But yes, Tim can do this. May be there is some low hanging fruit.
(In reply to Andrey Loskutov from comment #4) > (In reply to Matthias Sohn from comment #3) > > (In reply to Andrey Loskutov from comment #2) > > > (In reply to Matthias Sohn from comment #1) > > > > How many branches does your repository have ? > > > ~8000 - 9000, depends on current work load > > > > Why do you use so many branches ? > > Mostly remote tracking branches or local branches ? > > Remote tracking, I believe it is due many developers (~100?), many releases > (3 supported in parallel at least), lot of various "project" branches under > "master", lot of temporary bitbucket branches for code reviews, bug fixes > etc. That's one of the reasons why Gerrit uses refs in another namespace (not refs/heads) which isn't fetched by default. Do you need all these branches in your local clone ? Maybe you can use hierarchical branch names and selectively only fetch maintenance branches and master by default e.g. refs/heads/stable/rel-5.4 refs/heads/stable/rel-5.3 refs/heads/stable/rel-5.2 ... refs/heads/feature/foo refs/heads/feature/bar ... refs/heads/fix/bug-1234 refs/heads/fix/bug-1236 ... and use a custom config which only fetches the maintenance branches automatically [remote "origin"] url = https://git.host/sample/repo fetch = +refs/heads/master:refs/remotes/origin/master fetch = +refs/heads/*:refs/remotes/origin/stable/* then you could fetch the other branches you are interested in on demand and enjoy much less branches in your local clone. I would tend to delete feature and bug fix branches as soon as their review is done and the respective commits were merged to master or a stable branch. > @Tim: we should do some research where/why do we create most of the > branches, just in case we have some tooling issue. > > > How about profiling this to learn where so much time is spent ? > > I believe it is due the repo size on disk (~15 GB). But yes, Tim can do > this. May be there is some low hanging fruit.
We have implemented a similar background reading for the tags node of the repositories view in https://git.eclipse.org/r/#/c/120761/2/org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/repository/RepositoriesViewContentProvider.java However, there the expectation is that the tags node doesn't get expanded in most cases when loading the tree content. In contrast, the branch selection dialog needs all the branches in almost all cases. So I cannot really imagine an improvement besides the UI not freezing. In fact I would rather assume a bug, if I started typing "master" and don't see any match in the filtered tree, just because we are still loading in the background.
(In reply to Michael Keppler from comment #6) > We have implemented a similar background reading for the tags node of the > repositories view in > https://git.eclipse.org/r/#/c/120761/2/org.eclipse.egit.ui/src/org/eclipse/ > egit/ui/internal/repository/RepositoriesViewContentProvider.java > > However, there the expectation is that the tags node doesn't get expanded in > most cases when loading the tree content. In contrast, the branch selection > dialog needs all the branches in almost all cases. So I cannot really > imagine an improvement besides the UI not freezing. In fact I would rather > assume a bug, if I started typing "master" and don't see any match in the > filtered tree, just because we are still loading in the background. CreateTagDialog does load the tags in the background. It displays "Loading..." until it's done. Didn't investigate whether that method could be used here. Otherwise, there's the DeferredTreeContentManager; see for example its use in the Reflog view.
