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

Re: Efficient way to import snapshots?

From
David Kastrup <dak@gnu.org>
Date
Jul 31, 2007, 06:23 UTC
Message-ID
<85odht3xd1.fsf@lola.goethe.zz>
In-Reply-To
<alpine.LFD.0.999.0707301629230.4161@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
Show 11 quoted lines
> On Mon, 30 Jul 2007, Craig Boston wrote:
>> 
>> # On branch cvs_RELENG_4
>> nothing to commit (working directory clean)
>> git: 67.65 seconds
>
> So I _seriously_ hope that about 65 of those 67 seconds was the "cvs 
> update -d" or something like that. 
>
> Anything that takes a minute in git is way way *way* too slow. Any 
> half-way normal git operations should take less than a second.

I tried a git-add . on a TeX live tree (lots of itsy files). About 80% of the processor time was wait.

I think that SHA1 is costly enough that the processor(s) could get saturated when enough is done in parallel.

Potential for multithreading is here enough to make any Summer of Code student weep with joy:

a) one thread for opendir/readdir at every directory level
b) one thread for stating the files in readdir order (more likely to
   correspond to the disk layout than sorted order)
c) one thread on each directory level doing a mergesort on a different
   link field (some merge passes could be parallelized even, but let's
   not get overexcited)
d) asynch I/O requesting the data for all files to be submitted to
   SHA1
e) one thread (but no more threads than there are CPUs) per
   independent file/tree for doing SHA1
f) asynch I/O reading the index sequentially
g) one thread doing a merge pass of already sorted stuff (this can
   start once the top level directory has been read and sorted
   completely, possibly having to stop until a complete subdirectory
   comes in).
h) asynch I/O writing out the results of the merge sequentially

In fact, git-ls-files|git-add --stdin is already exploiting a bit of parallelism (and will probably profit from CFS by making much more use of the buffering capacity of the pipe). It is counterintuitive that hand-built chains work more efficiently than explicit git commands.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Previous: Theodore TsoNext: Florian Weimer
Message 23 of 27 in “Efficient way to import snapshots?”
  1. Craig BostonJul 30, 2007
  2. Linus TorvaldsJul 30, 2007
  3. Craig BostonJul 30, 2007
  4. Linus TorvaldsJul 30, 2007
  5. Craig BostonJul 30, 2007
  6. Junio C HamanoJul 30, 2007
  7. Craig BostonJul 30, 2007
  8. Junio C HamanoJul 30, 2007
  9. Linus TorvaldsJul 30, 2007
  10. Junio C HamanoJul 30, 2007
  11. Linus TorvaldsJul 30, 2007
  12. Junio C HamanoJul 30, 2007
  13. Linus TorvaldsJul 31, 2007
  14. Junio C HamanoJul 31, 2007
  15. Craig BostonJul 30, 2007
  16. Linus TorvaldsJul 30, 2007
  17. Craig BostonJul 31, 2007
  18. Linus TorvaldsJul 31, 2007
  19. Theodore TsoJul 31, 2007
  20. Craig BostonJul 31, 2007
  21. Linus TorvaldsJul 31, 2007
  22. Theodore TsoJul 31, 2007
  23. David KastrupJul 31, 2007
  24. Florian WeimerJul 31, 2007
  25. David KastrupJul 31, 2007
  26. Jakub NarebskiJul 30, 2007
  27. David KastrupJul 30, 2007

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.