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

Re: Bottlenecks in git merge

From
Petr Baudis <pasky@suse.cz>
Date
Jan 31, 2006, 23:27 UTC
Message-ID
<20060131232731.GA31278@pasky.or.cz>
In-Reply-To
<20060131213314.GA32131@ebar091.ebar.dtu.dk>
Hello,

Dear diary, on Tue, Jan 31, 2006 at 10:33:14PM CET, I got a letter where Peter Eriksen <s022018@student.dtu.dk> said that...

Show 10 quoted lines
> In connection with Ian Molton's question about merge have I played a
> little with 'git merge' on the kernel sources.  What I find is that a
> merge can take quite some time, but I'm not sure where that time exactly
> goes to.  Here are the times I got:
> 
> Recursive (default):  4m22.282s
> Resolve (-s resolve): 3m23.548s
> 
> 
> What is taking so long?

it is difficult to benchmark for me since everything required for the merge (that is, both all the objects and the whole working tree) just won't fit into my caches (or Linux at least won't let it stay there for long enough). I ended up repeatedly calling the subcommands, but that obviously is not a real world usage pattern. Proportionally, the significant eaters of time for cg-merge (similar to -s resolve) are:

git-merge-base       --- 1s cached, 10s to 20s uncached
git-read-tree -m     --- 1s cached, 10s or more uncached
git-read-tree -m -u  --- 1m50s w/ heavy disk activity, but big part of it
                         is writing blocks
git-merge-index -a \
	-o /bin/true --- 1s cached
git-merge-index -a \
	-o ~/cogito/cg-Xmergefile
                     --- 1m27s with some disk activity (44s user, 20s sys)
                         cg-Xmergefile is very similar to
			 git-merge-one-file

Note that the time spent by git-read-tree here is just checking out the new file versions, which is inevitable. ;-)

The real killer here is therefore git-merge-one-file. Most frequent hits here are probably of the added-in-one case, resulting in two more fork()s, reloading the index like mad all the time.

Comparing cg-merge to git-merge, one difference is that git-merge tries to do kind of "trivial" merge first (apparently even if -s was passed to it), the point of which kind of escapes me if you are using the resolve strategy, but which causes two git-update-index calls - even one can take good half a minute or more if your cache is cold.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe.  -- Douglas Adams
Previous: Linus TorvaldsNext: Junio C Hamano
Message 8 of 11 in “Bottlenecks in git merge”
  1. Peter EriksenJan 31, 2006
  2. Junio C HamanoJan 31, 2006
  3. Petr BaudisJan 31, 2006
  4. Junio C HamanoFeb 1, 2006
  5. Linus TorvaldsJan 31, 2006
  6. Petr BaudisFeb 1, 2006
  7. Linus TorvaldsFeb 1, 2006
  8. Petr BaudisJan 31, 2006
  9. read-tree --aggressiveJunio C Hamano, Feb 4, 2006
  10. Peter EriksenFeb 4, 2006
  11. Junio C HamanoFeb 4, 2006

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.