Re: [PATCH 4/7] for_each_packed_object: support iterating in pack-order

2018-08-16 Thread Jeff King
On Wed, Aug 15, 2018 at 09:28:44AM -0400, Derrick Stolee wrote:

> On 8/10/2018 7:15 PM, Jeff King wrote:
> > diff --git a/commit-graph.c b/commit-graph.c
> > index b0a55ad128..69a0d1c203 100644
> > --- a/commit-graph.c
> > +++ b/commit-graph.c
> > @@ -730,7 +730,7 @@ void write_commit_graph(const char *obj_dir,
> > die("error adding pack %s", packname.buf);
> > if (open_pack_index(p))
> > die("error opening index for %s", packname.buf);
> > -   for_each_object_in_pack(p, add_packed_commits, &oids);
> > +   for_each_object_in_pack(p, add_packed_commits, &oids, 
> > 0);
> > close_pack(p);
> > }
> 
> This use in write_commit_graph() is actually a good candidate for
> pack-order, since we are checking each object to see if it is a commit. This
> is only used when running `git commit-graph write --stdin-packs`, which is
> how VFS for Git maintains the commit-graph.
> 
> I have a note to run performance tests on this case and follow up with a
> change on top of this series that adds the FOR_EACH_OBJECT_PACK_ORDER flag.

I doubt that it will show the dramatic improvement in CPU that I
mentioned in my commit message, because most of that comes from more
efficient use of the delta cache. But it's very rare for commits to be
deltas (usually it's just almost-twins due to cherry-picks and rebases).

So you may benefit from block cache efficiency on a cold-cache or on a
system under memory pressure, but I wouldn't expect much change at all
for the warm-cache case.

I doubt it will hurt, though; you'll pay for the revindex generation,
but that's probably not a big deal compared to walking all the objects.

One thing you _could_ do is stop walking through the pack when you see a
non-commit, since we stick all of the commits at the front. But that's
just what the code happens to do, and not a strict promise. So I think
it's a bad idea to rely on it (and in fact the delta-islands work under
discussion elsewhere will break that assumption).

-Peff


Re: [PATCH 4/7] for_each_packed_object: support iterating in pack-order

2018-08-15 Thread Derrick Stolee

On 8/10/2018 7:15 PM, Jeff King wrote:

diff --git a/commit-graph.c b/commit-graph.c
index b0a55ad128..69a0d1c203 100644
--- a/commit-graph.c
+++ b/commit-graph.c
@@ -730,7 +730,7 @@ void write_commit_graph(const char *obj_dir,
die("error adding pack %s", packname.buf);
if (open_pack_index(p))
die("error opening index for %s", packname.buf);
-   for_each_object_in_pack(p, add_packed_commits, &oids);
+   for_each_object_in_pack(p, add_packed_commits, &oids, 
0);
close_pack(p);
}


This use in write_commit_graph() is actually a good candidate for 
pack-order, since we are checking each object to see if it is a commit. 
This is only used when running `git commit-graph write --stdin-packs`, 
which is how VFS for Git maintains the commit-graph.


I have a note to run performance tests on this case and follow up with a 
change on top of this series that adds the FOR_EACH_OBJECT_PACK_ORDER flag.


Thanks,

-Stolee



[PATCH 4/7] for_each_packed_object: support iterating in pack-order

2018-08-10 Thread Jeff King
We currently iterate over objects within a pack in .idx
order, which uses the object hashes. That means that it
is effectively random with respect to the location of the
object within the pack. If you're going to access the actual
object data, there are two reasons to move linearly through
the pack itself:

  1. It improves the locality of access in the packfile. In
 the cold-cache case, this may mean fewer disk seeks, or
 better usage of disk cache.

  2. We store related deltas together in the packfile. Which
 means that the delta base cache can operate much more
 efficiently if we visit all of those related deltas in
 sequence, as the earlier items are likely to still be
 in the cache.  Whereas if we visit the objects in
 random order, our cache entries are much more likely to
 have been evicted by unrelated deltas in the meantime.

So in general, if you're going to access the object contents
pack order is generally going to end up more efficient.

But if you're simply generating a list of object names, or
if you're going to end up sorting the result anyway, you're
better off just using the .idx order, as finding the pack
order means generating the in-memory pack-revindex.
According to the numbers in 8b8dfd5132 (pack-revindex:
radix-sort the revindex, 2013-07-11), that takes about 200ms
for linux.git, and 20ms for git.git (those numbers are a few
years old but are still a good ballpark).

That makes it a good optimization for some cases (we can
save tens of seconds in git.git by having good locality of
delta access, for a 20ms cost), but a bad one for others
(e.g., right now "cat-file --batch-all-objects
--batch-check="%(objectname)" is 170ms in git.git, so adding
20ms to that is noticeable).

Hence this patch makes it an optional flag. You can't
actually do any interesting timings yet, as it's not plumbed
through to any user-facing tools like cat-file. That will
come in a later patch.

Signed-off-by: Jeff King 
---
 cache.h|  5 +
 commit-graph.c |  2 +-
 packfile.c | 21 -
 packfile.h |  8 +---
 4 files changed, 27 insertions(+), 9 deletions(-)

diff --git a/cache.h b/cache.h
index f438540f9b..6d14702df2 100644
--- a/cache.h
+++ b/cache.h
@@ -1633,6 +1633,11 @@ enum for_each_object_flags {
 
/* Only iterate over packs obtained from the promisor remote. */
FOR_EACH_OBJECT_PROMISOR_ONLY = (1<<1),
+
+   /*
+* Visit objects within a pack in packfile order rather than .idx order
+*/
+   FOR_EACH_OBJECT_PACK_ORDER = (1<<2),
 };
 
 /*
diff --git a/commit-graph.c b/commit-graph.c
index b0a55ad128..69a0d1c203 100644
--- a/commit-graph.c
+++ b/commit-graph.c
@@ -730,7 +730,7 @@ void write_commit_graph(const char *obj_dir,
die("error adding pack %s", packname.buf);
if (open_pack_index(p))
die("error opening index for %s", packname.buf);
-   for_each_object_in_pack(p, add_packed_commits, &oids);
+   for_each_object_in_pack(p, add_packed_commits, &oids, 
0);
close_pack(p);
}
strbuf_release(&packname);
diff --git a/packfile.c b/packfile.c
index 9da8f6d728..ebcb5742ec 100644
--- a/packfile.c
+++ b/packfile.c
@@ -1885,19 +1885,30 @@ int has_pack_index(const unsigned char *sha1)
return 1;
 }
 
-int for_each_object_in_pack(struct packed_git *p, each_packed_object_fn cb, 
void *data)
+int for_each_object_in_pack(struct packed_git *p,
+   each_packed_object_fn cb, void *data,
+   enum for_each_object_flags flags)
 {
uint32_t i;
int r = 0;
 
+   if (flags & FOR_EACH_OBJECT_PACK_ORDER)
+   load_pack_revindex(p);
+
for (i = 0; i < p->num_objects; i++) {
+   uint32_t pos;
struct object_id oid;
 
-   if (!nth_packed_object_oid(&oid, p, i))
+   if (flags & FOR_EACH_OBJECT_PACK_ORDER)
+   pos = p->revindex[i].nr;
+   else
+   pos = i;
+
+   if (!nth_packed_object_oid(&oid, p, pos))
return error("unable to get sha1 of object %u in %s",
-i, p->pack_name);
+pos, p->pack_name);
 
-   r = cb(&oid, p, i, data);
+   r = cb(&oid, p, pos, data);
if (r)
break;
}
@@ -1922,7 +1933,7 @@ int for_each_packed_object(each_packed_object_fn cb, void 
*data,
pack_errors = 1;
continue;
}
-   r = for_each_object_in_pack(p, cb, data);
+   r = for_each_object_in_pack(p, cb, data, flags);
if (r)
break;
}
diff --git a/packfile.h b/packfile.h
index c86a8c2