git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: remove_duplicates() in builtin/fetch-pack.c is O(N^2)

From
MFMartin Fick <mfick@codeaurora.org>
Date
May 21, 2012, 18:15 UTC
Message-ID
<201205211215.14455.mfick@codeaurora.org>
In-Reply-To
<4FB9F92D.8000305@alum.mit.edu>
On Monday, May 21, 2012 02:13:33 am Michael Haggerty wrote:
Show 9 quoted lines
> I just noticed that the remove_duplicates() function in
> builtin/fetch-pack.c is O(N^2) in the number of heads. 
> Empirically, this function takes on the order of 25
> seconds to process 100k references.
> 
> I know that 100k heads is kindof absurd.  Perhaps
> handling this many heads is unrealistic for other
> reasons.  But I vaguely recall numbers like this being
> mentioned on the mailing list.

Yes I have mentioned 100K several times, and I greatly appreciate the many fixes already made to make git to better handle large ref counts.

However, I would like to suggest that 100K not really be viewed as absurd anymore. :) There are many users for whom it is not absurd, certainly not if you are including tags. But, I know that some of the tag uses have been brushed off as abuses, so I will focus on feature branches, of which we actually have more than tags in our larger repos, we have around 60K in our kernel repo.

Of course, we use Gerrit, so features tend to be called changes and each change may get many revisions (patchsets), so all of these get refs, but I think that it might be wrong to consider that out of the ordinary anymore. After all, should a version control system such as git not support 100K revisions of features developed independently on separate branches (within Gerrit or not)? 100K is not really that many when you consider a large project. Even without Gerrit, if someone wanted to track that many features (likely over a few years), they will probably use up tons of refs.

It may be too easy to think that because git is distributed that features will get developed in a distributed way and therefor no one would ever want to track them all in one place, but I suspect that this may be a bad assumption. That being said, I believe that we are not even tracking external features, and we have over 60K feature revisions (gerrit patchsets) in one rep), so if someone were to track all the changes for the kernel, I can only imagine that this number would be in the millions.

I am sure that 1M refs is even within the sights of some individuals already, I know users who actually have 250K. I hope that 10M or even perhaps 100M refs will be considered feasible to use long term with git.

Again, I really hope that this will no longer be seen as absurd, but rather just normal for large projects. After all the kernel was (still is?) the primary use case of git. Our largest ref project is the kernel so I don't know that we should be considered fringe, and I hope that we along with other larger kernel contributors will be considered normal to git, :)

-Martin
-- 
Employee of Qualcomm Innovation Center, Inc. which is a 
member of Code Aurora Forum
Previous: Junio C HamanoNext: Jeff King
Message 38 of 46 in “remove_duplicates() in builtin/fetch-pack.c is O(N^2)”
  1. Michael HaggertyMay 21, 2012
  2. Junio C HamanoMay 21, 2012
  3. demerphqMay 21, 2012
  4. Jeff KingMay 21, 2012
  5. Jeff KingMay 21, 2012
  6. 1/5 fetch-pack: sort incoming headsJeff King, May 21, 2012
  7. Junio C HamanoMay 22, 2012
  8. Jeff KingMay 22, 2012
  9. Jeff KingMay 24, 2012
  10. 2/5 fetch-pack: avoid quadratic behavior in remove_duplicatesJeff King, May 21, 2012
  11. 3/5 add sorting infrastructure for list refsJeff King, May 21, 2012
  12. 4/5 fetch-pack: sort the list of incoming refsJeff King, May 21, 2012
  13. 5/5 fetch-pack: avoid quadratic loop in filter_refsJeff King, May 21, 2012
  14. Junio C HamanoMay 22, 2012
  15. Jeff KingMay 21, 2012
  16. Jeff KingMay 22, 2012
  17. Michael HaggertyMay 22, 2012
  18. Jeff KingMay 22, 2012
  19. Michael HaggertyMay 22, 2012
  20. Jeff KingMay 22, 2012
  21. Michael HaggertyMay 22, 2012
  22. Jeff KingMay 22, 2012
  23. Michael HaggertyMay 24, 2012
  24. Martin FickMay 25, 2012
  25. Jeff KingMay 25, 2012
  26. Martin FickMay 25, 2012
  27. Jeff KingMay 25, 2012
  28. Martin FickMay 25, 2012
  29. Jeff KingMay 25, 2012
  30. Nguyen Thai Ngoc DuyMay 22, 2012
  31. Michael HaggertyMay 22, 2012
  32. Jeff KingMay 22, 2012
  33. Junio C HamanoMay 22, 2012
  34. Jeff KingMay 22, 2012
  35. Michael HaggertyMay 24, 2012
  36. Nguyen Thai Ngoc DuyMay 23, 2012
  37. Junio C HamanoMay 22, 2012
  38. Martin FickMay 21, 2012
  39. Jeff KingMay 21, 2012
  40. Junio C HamanoMay 21, 2012
  41. Jeff KingMay 21, 2012
  42. Martin FickMay 22, 2012
  43. Jeff KingMay 22, 2012
  44. Martin FickMay 22, 2012
  45. Junio C HamanoMay 22, 2012
  46. Martin FickMay 23, 2012

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.