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

Re: [PATCH 0/7] [GSoC2009] Revision cache / git-daemon caching plan

From
Jakub Narebski <jnareb@gmail.com>
Date
Jun 5, 2009, 16:56 UTC
Message-ID
<m34ouu7h70.fsf@localhost.localdomain>
In-Reply-To
<cover.1244125127.git.sam@vilain.net>
Sam Vilain <sam@vilain.net> writes:
Show 19 quoted lines
> This patch series describes the structure of the object list cache
> on-disk format.  It is built successively from a very simple design -
> just an object list - to a version that allows for as many rev-list
> operations to be accelerated as possible, and potentially immediate
> startup of full clone operations in the common case; ie skipping the
> "Counting Objects" and "Compressing Objects" phase once a matching
> index is found.
> 
> The plan will be to implement each step incrementally, with a test-*.c
> file along the way which tests the API provided by the revision cache
> API.  While the revision cache format will change along the way, this
> will not require an index format deprecation cycle, as integration with
> the rest of git will not happen until the format is settled.
> 
> The plan is to aim for one of these API milestones completed per week.
> When complete, each commit will contain tests for the level of cache
> that it delivers.  Later milestones include joining the dots -
> integrating with the 'rev-list' machinery and most importantly,
> 'pack-objects'.

I like this sharing not only completed code, but plans, designs (and status reports) with Git Development Community (i.e. git mailing list). I like this very much.

I'd like to ask if there any results of profiling git server (git-daemon) code: how much is spend on object enumeration this GSoC project tries to make faster by the means of caching?

Are there prepared benchmarks and tests to check if the code gives correct results, and to measure improvements brought by caching? Would it be possible to get some real-life statistics of git-daemon usage, so that you optimize against real scenarios?

I wish you good work on git-daemon caching...
-- 
Jakub Narebski
Poland
ShadeHawk on #git
Previous: Sam VilainNext: Nicolas Pitre
Message 12 of 14 in “[GSoC2009] Revision cache / git-daemon caching plan”
  1. 0/7 [GSoC2009] Revision cache / git-daemon caching planSam Vilain, Jun 4, 2009
  2. 2/7 rev-cache: add on-disk format for fast reachability lookupSam Vilain, Jun 4, 2009
  3. 5/7 revision cache: maps of 'new' objectsSam Vilain, Jun 4, 2009
  4. 4/7 rev-cache: allow multiple 'start' objects per indexSam Vilain, Jun 4, 2009
  5. 1/7 revision-cache: define revision cache as simple list of revisionsSam Vilain, Jun 4, 2009
  6. Nicolas PitreJun 5, 2009
  7. Sam VilainJun 7, 2009
  8. Nicolas PitreJun 7, 2009
  9. 3/7 rev-cache: add 'end' objects for caching 'uninteresting' lookupsSam Vilain, Jun 4, 2009
  10. 7/7 revision cache: be even stricter with sort orderSam Vilain, Jun 4, 2009
  11. 6/7 revision cache: allow foreign 'start' commitsSam Vilain, Jun 4, 2009
  12. Jakub NarebskiJun 5, 2009
  13. Nicolas PitreJun 5, 2009
  14. Sam VilainJun 7, 2009

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.