Re: git-svn performance

4 messages, 2 authors, 2016-06-15 · open the first message on its own page

Re: git-svn performance

From: Hin-Tak Leung <hidden>
Date: 2016-06-15 23:02:46

------------------------------
On Tue, Oct 21, 2014 10:00 BST Eric Wong wrote:
quoted hunk
Jakob Stoklund Olesen [off-list ref] wrote:
quoted
Yes, but I think you can remove cached_mergeinfo_rev too. 
Thanks, pushed the patch at the bottom, too.
Also started working on some memory reductions here:
http://mid.gmane.org/20141021033912.GA27462@dcvr.yhbt.net
But there seem to be more problems :<

----------------------------8<-----------------------------
From: Eric Wong <redacted>
Date: Tue, 21 Oct 2014 06:23:22 +0000
Subject: [PATCH] git-svn: remove mergeinfo rev caching

This should further reduce memory usage from the new mergeinfo
speedups without hurting performance too much, assuming
reasonable latency to the SVN server.

Cc: Hin-Tak Leung <redacted>
Suggested-by: Jakob Stoklund Olesen <redacted>
Signed-off-by: Eric Wong <redacted>
---
perl/Git/SVN.pm | 30 +++++++++---------------------
1 file changed, 9 insertions(+), 21 deletions(-)
diff --git a/perl/Git/SVN.pm b/perl/Git/SVN.pm
index f8a75b1..4364506 100644
--- a/perl/Git/SVN.pm
+++ b/perl/Git/SVN.pm
@@ -1710,32 +1710,20 @@ sub mergeinfo_changes {
    my %minfo = map {split ":", $_ } split "\n", $mergeinfo_prop;
    my $old_minfo = {};

-    # Initialize cache on the first call.
-    unless (defined $self->{cached_mergeinfo_rev}) {
-        $self->{cached_mergeinfo_rev} = {};
-    }
-
-    my $cached_rev = $self->{cached_mergeinfo_rev}{$old_path};
-    unless (defined $cached_rev && $cached_rev == $old_rev) {
-        my $ra = $self->ra;
-        # Give up if $old_path isn't in the repo.
-        # This is probably a merge on a subtree.
-        if ($ra->check_path($old_path, $old_rev) != $SVN::Node::dir) {
-            warn "W: ignoring svn:mergeinfo on $old_path, ",
-                "directory didn't exist in r$old_rev\n";
-            return {};
-        }
-    }
-    my (undef, undef, $props) = $self->ra->get_dir($old_path, $old_rev);
+    my $ra = $self->ra;
+    # Give up if $old_path isn't in the repo.
+    # This is probably a merge on a subtree.
+    if ($ra->check_path($old_path, $old_rev) != $SVN::Node::dir) {
+        warn "W: ignoring svn:mergeinfo on $old_path, ",
+            "directory didn't exist in r$old_rev\n";
+        return {};
+    }
+    my (undef, undef, $props) = $ra->get_dir($old_path, $old_rev);
    if (defined $props->{"svn:mergeinfo"}) {
        my %omi = map {split ":", $_ } split "\n",
            $props->{"svn:mergeinfo"};
        $old_minfo = \%omi;
    }
-    $self->{cached_mergeinfo_rev}{$old_path} = $old_rev;
-
-    # Cache the new mergeinfo.
-    $self->{cached_mergeinfo_rev}{$path} = $rev;

    my %changes = ();
    foreach my $p (keys %minfo) {
-- 
EW
I'll have a look at the new changes at some point - I am still keeping the old
clone and the new clone and just fetching from time to time to keep them
in sync. I just tried that and fetching the same 50 commits on the old clone 
took 1.7 GB memory vs 1.0 GB memory on the new. Details below.
This is just with the 2 earliest patches - I'll put the new 3 in at some point.
So I see some needs for retrospectively fixing old clones (maybe as part
of garbage collection?), since most would simply use an old clone through
the ages... 

Comparing trunk of old and new, I see one difference -  One short
commit message is missing in the *old* (the "Add checkPoFiles etc." part)
and so all the sha1 afterwards differed. Is that an old bug that's fixed
and therefore I should throw away the old clone? 

Date:   Wed Apr 25 18:21:29 2012 +0000
    Add checkPoFiles etc.
        git-svn-id: https://svn.r-project.org/R/trunk@59188 

Here is the details of fetching old and new:

<---
$ /usr/bin/time -v git svn fetch --all
	M	doc/manual/R-admin.texi
r66784 = fc20374f26f8e03bb88c00933982e29138a6f929 (refs/remotes/trunk)
...
	M	configure
r66834 = d8d1876f6aa71b3fe3773cd28a760ff945d30bdf (refs/remotes/R-3-1-branch)
	Command being timed: "git svn fetch --all"
	User time (seconds): 1520.77
	System time (seconds): 156.32
	Percent of CPU this job got: 98%
	Elapsed (wall clock) time (h:mm:ss or m:ss): 28:15.82
	Average shared text size (kbytes): 0
	Average unshared data size (kbytes): 0
	Average stack size (kbytes): 0
	Average total size (kbytes): 0
	Maximum resident set size (kbytes): 1738276
	Average resident set size (kbytes): 0
	Major (requiring I/O) page faults: 613
	Minor (reclaiming a frame) page faults: 2039305
	Voluntary context switches: 11243
	Involuntary context switches: 181507
	Swaps: 0
	File system inputs: 658328
	File system outputs: 754688
	Socket messages sent: 0
	Socket messages received: 0
	Signals delivered: 0
	Page size (bytes): 4096
	Exit status: 0

$ cd ../R-2/
[Hin-Tak@localhost R-2]$ /usr/bin/time -v git svn fetch --all
	M	doc/manual/R-admin.texi
r66784 = 6a08d94b456d33d85add914a1b780a972689443a (refs/remotes/trunk)
...
	M	configure
r66834 = 370a6484c2a65be78dfae184b50d8f08685d389c (refs/remotes/R-3-1-branch)
	Command being timed: "git svn fetch --all"
	User time (seconds): 1507.89
	System time (seconds): 134.25
	Percent of CPU this job got: 99%
	Elapsed (wall clock) time (h:mm:ss or m:ss): 27:38.49
	Average shared text size (kbytes): 0
	Average unshared data size (kbytes): 0
	Average stack size (kbytes): 0
	Average total size (kbytes): 0
	Maximum resident set size (kbytes): 1026656
	Average resident set size (kbytes): 0
	Major (requiring I/O) page faults: 1110
	Minor (reclaiming a frame) page faults: 1630150
	Voluntary context switches: 10280
	Involuntary context switches: 176444
	Swaps: 0
	File system inputs: 361472
	File system outputs: 477912
	Socket messages sent: 0
	Socket messages received: 0
	Signals delivered: 0
	Page size (bytes): 4096
	Exit status: 0
---->

Anomaly with the new code - Re: git-svn performance

From: Hin-Tak Leung <hidden>
Date: 2016-06-15 23:02:46

I keep tabs of a particular svn repository over many years
and run "git svn fetch --all" every few days. So that's the old clone.
Since this discussion started, I made a new one with git 2.1.0 patched
with the first two patches below, a couple of weeks ago. And I ran
'git svn fetch --all' on both every few days since.

I have added a few more patches, so the whole list is the 6
below against 2.1.0. The latest fetch is really strange - the fetch against
the new clone took almost twice as long and uses almost twice
as much memory, vs against the old. 17 min, 800 MB vs 10 min 400MB.
Details below. Maybe this is a performance issue about how the clones
were made?

0001-git-svn-only-look-at-the-new-parts-of-svn-mergeinfo.patch    
0002-git-svn-only-look-at-the-root-path-for-svn-mergeinfo.patch   
0003-git-svn-reduce-check_cherry_pick-cache-overhead.patch        
0004-git-svn-cache-only-mergeinfo-revisions.patch                 
0006-git-svn-clear-global-SVN-pool-between-get_log-invoca.patch   
0007-git-svn-remove-mergeinfo-rev-caching.patch 

(I dropped #5 because it doesn't seem interesting?)

<---
$ /usr/bin/time -v git svn fetch --all
...
	Command being timed: "git svn fetch --all"
	User time (seconds): 622.20
	System time (seconds): 12.52
	Percent of CPU this job got: 98%
	Elapsed (wall clock) time (h:mm:ss or m:ss): 10:42.21
	Average shared text size (kbytes): 0
	Average unshared data size (kbytes): 0
	Average stack size (kbytes): 0
	Average total size (kbytes): 0
	Maximum resident set size (kbytes): 399588
	Average resident set size (kbytes): 0
	Major (requiring I/O) page faults: 320
	Minor (reclaiming a frame) page faults: 383987
	Voluntary context switches: 2088
	Involuntary context switches: 68304
	Swaps: 0
	File system inputs: 168288
	File system outputs: 148960
	Socket messages sent: 0
	Socket messages received: 0
	Signals delivered: 0
	Page size (bytes): 4096
	Exit status: 0
[Hin-Tak@localhost R]$ cd ../R-2/
[Hin-Tak@localhost R-2]$ /usr/bin/time -v git svn fetch --all
	M	src/library/stats/R/hclust.R
	M	src/library/stats/R/dendrogram.R
r66853 = 7c18b2e4084529d5912cf789c045f2eab7d4083c (refs/remotes/trunk)
	M	doc/manual/R-exts.texi
r66854 = bc7b131e34eaf04859fede1ecedb796c0a33be02 (refs/remotes/trunk)
	M	doc/manual/R-exts.texi
Checking svn:mergeinfo changes since r66844: 6 sources, 1 changed
W:svn cherry-pick ignored (/trunk:66824,66854) - missing 1084 commit(s) (eg 6453a2d844e27f2963ba87142028b023c50385ef)
r66855 = de5daf8db948732fa96c3d5b32077d8057e2a7e7 (refs/remotes/R-3-1-branch)
	M	src/modules/internet/internet.c
r66856 = a1e9300c6dd49ec4c3dd11f861bca0dbe3ca65b4 (refs/remotes/trunk)
	M	doc/manual/R-admin.texi
r66857 = eb5f3175e67a806482c39def71246f5d18bf8660 (refs/remotes/trunk)
	M	doc/manual/R-admin.texi
Checking svn:mergeinfo changes since r66855: 6 sources, 1 changed
W:svn cherry-pick ignored (/trunk:66854,66857) - missing 1086 commit(s) (eg e8cc0c31ddeeea3f8fa1ad47105d09a2c19e1a98)
r66858 = 10c8013f103d57c8a717b738e2a51c8d397c88f0 (refs/remotes/R-3-1-branch)
	M	VERSION
r66859 = 0f865f247da3191431bb17bcc3c307e8735dbd97 (refs/remotes/R-3-1-branch)
	Command being timed: "git svn fetch --all"
	User time (seconds): 1023.06
	System time (seconds): 15.30
	Percent of CPU this job got: 99%
	Elapsed (wall clock) time (h:mm:ss or m:ss): 17:27.65
	Average shared text size (kbytes): 0
	Average unshared data size (kbytes): 0
	Average stack size (kbytes): 0
	Average total size (kbytes): 0
	Maximum resident set size (kbytes): 785332
	Average resident set size (kbytes): 0
	Major (requiring I/O) page faults: 884
	Minor (reclaiming a frame) page faults: 527668
	Voluntary context switches: 2792
	Involuntary context switches: 107718
	Swaps: 0
	File system inputs: 194704
	File system outputs: 170032
	Socket messages sent: 0
	Socket messages received: 0
	Signals delivered: 0
	Page size (bytes): 4096
	Exit status: 0

--->

Re: Anomaly with the new code - Re: git-svn performance

From: Eric Wong <hidden>
Date: 2016-06-15 23:02:47

Hin-Tak Leung [off-list ref] wrote:
I keep tabs of a particular svn repository over many years
and run "git svn fetch --all" every few days. So that's the old clone.
Since this discussion started, I made a new one with git 2.1.0 patched
with the first two patches below, a couple of weeks ago. And I ran
'git svn fetch --all' on both every few days since.

I have added a few more patches, so the whole list is the 6
below against 2.1.0. The latest fetch is really strange - the fetch against
the new clone took almost twice as long and uses almost twice
as much memory, vs against the old. 17 min, 800 MB vs 10 min 400MB.
Details below. Maybe this is a performance issue about how the clones
were made?
Memory usage seems to grow with the amount of revisions fetched,
see below.  And higher memory means slower fork() on Linux systems.
0001-git-svn-only-look-at-the-new-parts-of-svn-mergeinfo.patch    
0002-git-svn-only-look-at-the-root-path-for-svn-mergeinfo.patch   
0003-git-svn-reduce-check_cherry_pick-cache-overhead.patch        
0004-git-svn-cache-only-mergeinfo-revisions.patch                 
0006-git-svn-clear-global-SVN-pool-between-get_log-invoca.patch   
0006 is insufficient and incompatible with older SVN.
I pushed "git-svn: reload RA every log-window-size"
(commit dfa72fdb96befbd790f623bb2909a347176753c2) instead
which saves much more memory:

http://mid.gmane.org/20141024225352.GB31716@dcvr.yhbt.net

But there still seems to be some slow growth with many revisions
which is not mergeinfo-related.
0007-git-svn-remove-mergeinfo-rev-caching.patch 
I think it is also safe to remove the _rev_list memoization since
it uses a lot of memory.  The remaining caches should be tiny
(but useful, I think).

Re: git-svn performance

From: Eric Wong <hidden>
Date: 2016-06-15 23:02:47

Hin-Tak Leung [off-list ref] wrote:
Comparing trunk of old and new, I see one difference -  One short
commit message is missing in the *old* (the "Add checkPoFiles etc." part)
and so all the sha1 afterwards differed. Is that an old bug that's fixed
and therefore I should throw away the old clone? 
I don't recall a bug which would cause a revision to be skipped.
I suppose it's alright now the new clone has that revision.
Perhaps there was a power outage or improper shutdown?

At least we can be glad current versions see this revision...
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help