66 patches and counting

My renovation of refs.c [1] is currently at 66 patches and counting.
What can I say?: (1) I like to make changes in the smallest irreducible
steps and (2) there is a lot that needed to be done in refs.c.

When I'm done, is it OK to dump a patch series like that on the git
mailing list?  Is it pointless because nobody will review them anyway?
Is a big pile of changes like this welcome in any form?  Would it be
better to convey the changes via git itself (e.g., github) rather than
via emails?

Michael

[1] hierarchical-refs at git://github.com/mhagger/git.git

-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/

(+cc: Elijah, who has more experience in this subject than I do)
Hi,

Michael Haggerty wrote:

My renovation of refs.c [1] is currently at 66 patches and counting.
What can I say?: (1) I like to make changes in the smallest irreducible
steps and (2) there is a lot that needed to be done in refs.c.

When I'm done

We've seen series with fifty-something patches on this list before.
My (generic) advice:

 1. Send in installments, early and often.  It would not be fun if the
    first ten patches have a fatal flaw that means the later ones have
    to be reworked.

 2. Make sure the cover letter makes people want to read the later
    patches.  Make sure each patch has a commit message that motivates
    it alone or explains how it fits into the larger picture.

 3. When a patch is not intended to cause any functional change, say
    so, so reviewers can check that.

 4. Include test scripts declaring what effect (or lack thereof) each
    patch is supposed to have.

 5. "Smallest irreducible step" is not necessarily the appropriate
    granularity when publishing.  "Largest piece that a person would
    want to review, apply, or revert independently" is.

On Wednesday, October 05, 2011 03:29:57 pm Michael Haggerty 
wrote:

My renovation of refs.c [1] is currently at 66 patches
and counting. What can I say?: (1) I like to make
changes in the smallest irreducible steps and (2) there
is a lot that needed to be done in refs.c.

When I'm done, is it OK to dump a patch series like that
on the git mailing list?  Is it pointless because nobody
will review them anyway? Is a big pile of changes like
this welcome in any form?  Would it be better to convey
the changes via git itself (e.g., github) rather than
via emails?

Michael

[1] hierarchical-refs at git://github.com/mhagger/git.git

Michael,

I downloaded your patch series and tested it on my repos.

Here are some of the timings I saw with your branch as is:

 * git clone                               2:50m  (same)
 * full fetch changes                  (> 1 hour) (bad!)
 * git branch (unpacked, ungced)            .7s   (good!)
 * git branch (packed, gced)                .18s  (~>same)
 * git checkout (unpacked, ungced)          10.5s (~>same)
 * git checkout (packed, gced)               9.5  (~>same)
 * noop fetch changes (unpacked, ungced)    14s   (~>same)
 * noop fetch changes (packed, gced)        12s   (same)

For the full fetch, I estimated, things were scrolling by 
slow enough that after about 15 min I interrupted it. I 
suspect it might be at least 6 times longer (if rate stayed 
the same).


Here are the best timings for all the good patches that 
others have submitted to fix many of the previous problems I 
brought up:

 * git clone                               2:50m
 * full fetch changes                      4:50m   
 * git branch (unpacked, ungced)              9s
 * git branch (packed, gced)                  .05s
 * git checkout (unpacked, ungced)            9s
 * git checkout (packed, gced)                8s
 * noop fetch changes (unpacked, ungced)     12s
 * noop fetch changes (packed, gced)         12s

(my internal patches bring full fetch down to 2:50m)

It would be nice if you could rebase your work on top of 
some of the other patches also so that I could see those 
results. I might give that a try if I have the time and it 
is easy (or I might rebase those patches on yours).

Thanks,

-Martin

-- 
Employee of Qualcomm Innovation Center, Inc. which is a 
member of Code Aurora Forum

On Thursday, October 06, 2011 04:16:39 pm Martin Fick wrote:

On Wednesday, October 05, 2011 03:29:57 pm Michael
Haggerty

quoted

[1] hierarchical-refs at
git://github.com/mhagger/git.git

I downloaded your patch series and tested it on my repos.

 * full fetch changes                  (> 1 hour) (bad!)

I bisected this problem, it was introduced in this commit:


  commit e12ce45b4f1bd8ed6652a742b7e6cf6f101b3604
  Author: Michael Haggerty [off-list ref]
  Date:   Wed Oct 5 11:30:06 2011 +0200

    Store references hierarchically
    
    This slightly changes the order of iteration over 
references; now
    references are strictly sorted componentwise rather than 
as
    "/"-containing strings as before.  For example, 
"subspace/one" now
    sorts before "subspace-x", whereas before the order was 
reversed.
    
    Tweak a test case to accept the new ordering.



Up until that point, the fetch looks pretty good,

-Martin

-- 
Employee of Qualcomm Innovation Center, Inc. which is a 
member of Code Aurora Forum

On 10/07/2011 12:16 AM, Martin Fick wrote:

I downloaded your patch series and tested it on my repos.

Very cool (though a bit premature, as you discovered).  The patch series
still has a known performance regression in the area of
do_for_each_ref(), which I hope to figure out soon.  I will definitely
tell you when I think that the patch series is ready for more serious
testing (hopefully today) in the hopes that you can benchmark it against
your repo.

In the future, please tell me the SHA1 of any versions that you test, as
I am still frequently non-ff updating the hierarchical-refs branch.

Here are the best timings for all the good patches that 
others have submitted to fix many of the previous problems I 
brought up:

What are, in your measurements, the "good patches" that you consider
contenders performance-wise?  (I've lost track because there have been
so many suggestions in this area.)

It would be great if you would serve as a kind of benchmarking
referee/clearinghouse for the various suggested patches.  I have been
benchmarking with some rough scripts that I wrote [1]; the current
status is appended below (the numbers are clock times in seconds).  FWIW
the attached output was generated using roughly the following commands:

t/make-refperf-repo --refs=10000 --commits=20000
cp t/refperf-many .
# Adjust REFPERF_BRANCH in ./refperf-many:
$EDITOR ./refperf-many
revs="v1.7.6 v1.7.7 origin/master origin/hierarchical-refs^^
origin/hierarchical-refs^ origin/hierarchical-refs origin/master"
./refperf-many $revs
t/refperf-summary $revs >refperf-summary.out

See the comments at the top of the scripts for more details.  Please
suggest more tests to be added to t/refperf!

It would be nice if you could rebase your work on top of 
some of the other patches also so that I could see those 
results. I might give that a try if I have the time and it 
is easy (or I might rebase those patches on yours).

I believe that at least some of the other patches will be superseded by
mine.  When I get my patch series done I will look into it in more detail...

Michael

[1] Branch "refperf" at git://github.com/mhagger/git.git

-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/

On 10/07/2011 05:14 AM, Michael Haggerty wrote:

On 10/07/2011 12:16 AM, Martin Fick wrote:

quoted

I downloaded your patch series and tested it on my repos.

Very cool (though a bit premature, as you discovered).  The patch series
still has a known performance regression in the area of
do_for_each_ref(), which I hope to figure out soon.  I will definitely
tell you when I think that the patch series is ready for more serious
testing (hopefully today) in the hopes that you can benchmark it against
your repo.

I just pushed versions to github that I think are ready for some
preliminary testing.  There were some silly inefficiencies in the
version that you tested earlier, so this version is considerably faster
in a few key tests.

I don't have complete benchmarking results, but I have attached what I
have.  I wouldn't put much weight on small differences in the numbers
because the computer was not 100% quiescent while I ran the tests.  But
I think the results are impressive: the new code (columns 5-8) is a bit
slower in only a few cases but faster (sometimes by a large factor) in
many other cases.

I can't write more now, but Martin, if you have time to benchmark
9944c7faf903a95d4ed9de284ace32debe21cdc1 against your repository, I
would be very interested to learn the results.

BTW I am not asking anybody to review the patch series yet; I would like
to do some more tests and cleanup first.  But of course I wouldn't
object to feedback.  A good starting point would be the comments at the
top of refs.c, where the basic data structures are explained.

Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/

On Friday, October 07, 2011 09:51:46 am Michael Haggerty 
wrote:

I can't write more now, but Martin, if you have time to
benchmark 9944c7faf903a95d4ed9de284ace32debe21cdc1
against your repository, I would be very interested to
learn the results.

The fetch no longer seems to suffer from the large 
regression, it is now faster (~7m) than 1.7.7 (which was 
+15m).


As a quick note, if I comment out the 
invalidate_cached_refs() call in write_ref_sha1() on line  
2065 (on top of 9944c7), it is still much faster, only ~2m.  
Perhaps growing the array on the fly with many refs is still 
be too inefficient?


-Martin

-- 
Employee of Qualcomm Innovation Center, Inc. which is a 
member of Code Aurora Forum