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

Re: [PATCH] git-svn: cache max revision in rev_db databases

From
Sam Vilain <sam@vilain.net>
Date
Jun 11, 2007, 11:43 UTC
Message-ID
<466D357A.8070605@vilain.net>
In-Reply-To
<20070610214753.GC12222@muzzle>
Eric Wong wrote:
Show 14 quoted lines
> Sam Vilain <sam@vilain.net> wrote:
>   
>> Cache the maximum revision for each rev_db URL rather than looking it
>> up each time.  This saves a lot of time when rebuilding indexes on a
>> freshly cloned repository.
>>     
>
> It looks correct, but I'm not sure how often we can even hit this
> optimization to make it worth it.
>
> Any live repositories and benchmarks you've run this on?
> (without the rev-list => log patch applied, which would be a big
> performance improvement if all log messages were under 16k).
>

It may not make a huge difference with the current code, but it might with a different rev_db back-end with higher connection cost, and it seemed like an obvious and innocuous enough memoization.

Sam
Previous: Eric Wong
Message 3 of 3 in “git-svn: cache max revision in rev_db databases”
  1. git-svn: cache max revision in rev_db databasesSam Vilain, Jun 10, 2007
  2. Eric WongJun 10, 2007
  3. Sam VilainJun 11, 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.