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

3 messages from 2007-06-10 to 2007-06-11. Participants: Sam Vilain, Eric Wong.
Thread: https://gitlist.dev/t/8538

## Sam Vilain, 2007-06-10 09:04

Subject: [PATCH] git-svn: cache max revision in rev_db databases
Message-ID: <20070610091304.C3E0413A4F8@magnus.utsl.gen.nz>
URL: https://gitlist.dev/e/20070610091304.C3E0413A4F8%40magnus.utsl.gen.nz

```
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.

Signed-off-by: Sam Vilain <sam@vilain.net>
---
 git-svn.perl |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/git-svn.perl b/git-svn.perl
index 610563c..c9758a0 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -804,6 +804,7 @@ sub working_head_info {
 	my ($head, $refs) = @_;
 	my ($fh, $ctx) = command_output_pipe('log', $head);
 	my $hash;
+	my %max;
 	while (<$fh>) {
 		if ( m{^commit ($::sha1)$} ) {
 			$hash = $1;
@@ -812,11 +813,14 @@ sub working_head_info {
 		next unless s{^\s+(git-svn-id:)}{$1};
 		my ($url, $rev, $uuid) = extract_metadata($_);
 		if (defined $url && defined $rev) {
+			next if $max{$url} and $max{$url} < $rev;
 			if (my $gs = Git::SVN->find_by_url($url)) {
 				my $c = $gs->rev_db_get($rev);
 				if ($c && $c eq $hash) {
 					close $fh; # break the pipe
 					return ($url, $rev, $uuid, $gs);
+				} else {
+					$max{$url} ||= $gs->rev_db_max;
 				}
 			}
 		}
-- 
1.5.0.4.210.gf8a7c-dirty

```

## Eric Wong, 2007-06-10 21:47

Subject: Re: [PATCH] git-svn: cache max revision in rev_db databases
Message-ID: <20070610214753.GC12222@muzzle>
URL: https://gitlist.dev/e/20070610214753.GC12222%40muzzle
In-Reply-To: <20070610091304.C3E0413A4F8@magnus.utsl.gen.nz>

```
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).

> Signed-off-by: Sam Vilain <sam@vilain.net>
> ---
>  git-svn.perl |    4 ++++
>  1 files changed, 4 insertions(+), 0 deletions(-)
> 
> diff --git a/git-svn.perl b/git-svn.perl
> index 610563c..c9758a0 100755
> --- a/git-svn.perl
> +++ b/git-svn.perl
> @@ -804,6 +804,7 @@ sub working_head_info {
>  	my ($head, $refs) = @_;
>  	my ($fh, $ctx) = command_output_pipe('log', $head);
>  	my $hash;
> +	my %max;
>  	while (<$fh>) {
>  		if ( m{^commit ($::sha1)$} ) {
>  			$hash = $1;
> @@ -812,11 +813,14 @@ sub working_head_info {
>  		next unless s{^\s+(git-svn-id:)}{$1};
>  		my ($url, $rev, $uuid) = extract_metadata($_);
>  		if (defined $url && defined $rev) {
> +			next if $max{$url} and $max{$url} < $rev;
>  			if (my $gs = Git::SVN->find_by_url($url)) {
>  				my $c = $gs->rev_db_get($rev);
>  				if ($c && $c eq $hash) {
>  					close $fh; # break the pipe
>  					return ($url, $rev, $uuid, $gs);
> +				} else {
> +					$max{$url} ||= $gs->rev_db_max;
>  				}
>  			}
>  		}

-- 
Eric Wong

```

## Sam Vilain, 2007-06-11 11:43

Subject: Re: [PATCH] git-svn: cache max revision in rev_db databases
Message-ID: <466D357A.8070605@vilain.net>
URL: https://gitlist.dev/e/466D357A.8070605%40vilain.net
In-Reply-To: <20070610214753.GC12222@muzzle>

```
Eric Wong wrote:
> 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

```