On Wed, Nov 18, 2015 at 03:40:02PM -0800, Terry Parker wrote: > > +Terry, who did optimize the JGit implementation for bitmaps, > > as we also had a "lots of refs" hoarder repo, which underperformed > > before. > > The performance issue with the "hoarder" repo was that the bitmap > commit selection algorithm in JGit was selecting too many commits and > the hoarder repo caused OOMs. > > JGit's selection algorithm walks each branch and makes sure commits > are selected every 100-200 commits for "recent" history and every > 5000-5100 commits for more distant history. IIUC cgit sorts all commits > by date and does a similar selection. Since it doesn't attempt to get > even coverage on each branch, the selected commits may have > large gaps for a particular branch. Thanks for the data point. I agree that cgit seems to have the opposite problem: selecting fewer commits, which gives worse performance at read time, but no OOM at write time. :) I suspect there's some low-hanging fruit in tweaking cgit's implementation, where we might be able to do a better job of hitting near the tips of tags without having to drastically increase the number of bitmapped commits. But I haven't looked closely. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html