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

Re: git-svn metadata commands performance issue

From
David Kastrup <dak@gnu.org>
Date
Jan 15, 2015, 11:53 UTC
Message-ID
<87sifcdzul.fsf@fencepost.gnu.org>
In-Reply-To
<20150114203012.GA26023@dcvr.yhbt.net>
Eric Wong <normalperson@yhbt.net> writes:
> How big is the parent process which forks the git commands?  On Linux at
> least, fork() performance is negatively impacted by parent process
> memory size.

Huh. I thought with the advent of demand-paging, at the very least with copy-on-write, this was supposed to be sort of a non-issue.

The old original UNIX version, in contrast, consisted of swapping out the current process without removing the in-memory copy. But since the in-memory copy then did the exec call and since usually the exec call was happy about every page of free memory (we _are_ talking about something like 64kB of total available memory here), that tended to work reasonably well.

-- 
David Kastrup
Previous: Niluge kiwi
Message 5 of 5 in “git-svn metadata commands performance issue”
  1. Niluge kiwiJan 13, 2015
  2. Eric WongJan 14, 2015
  3. git-svn: lazy load some modulesEric Wong, Jan 15, 2015
  4. Niluge kiwiJan 15, 2015
  5. David KastrupJan 15, 2015

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.