2008-02-28 05:25:17 +00:00
|
|
|
#include "cache.h"
|
|
|
|
#include "pack-revindex.h"
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Pack index for existing packs give us easy access to the offsets into
|
|
|
|
* corresponding pack file where each object's data starts, but the entries
|
|
|
|
* do not store the size of the compressed representation (uncompressed
|
|
|
|
* size is easily available by examining the pack entry header). It is
|
|
|
|
* also rather expensive to find the sha1 for an object given its offset.
|
|
|
|
*
|
pack-revindex: drop hash table
The main entry point to the pack-revindex code is
find_pack_revindex(). This calls revindex_for_pack(), which
lazily computes and caches the revindex for the pack.
We store the cache in a very simple hash table. It's created
by init_pack_revindex(), which inserts an entry for every
packfile we know about, and we never grow or shrink the
hash. If we ever need the revindex for a pack that isn't in
the hash, we die() with an internal error.
This can lead to a race, because we may load more packs
after having called init_pack_revindex(). For example,
imagine we have one process which needs to look at the
revindex for a variety of objects (e.g., cat-file's
"%(objectsize:disk)" format). Simultaneously, git-gc is
running, which is doing a `git repack -ad`. We might hit a
sequence like:
1. We need the revidx for some packed object. We call
find_pack_revindex() and end up in init_pack_revindex()
to create the hash table for all packs we know about.
2. We look up another object and can't find it, because
the repack has removed the pack it's in. We re-scan the
pack directory and find a new pack containing the
object. It gets added to our packed_git list.
3. We call find_pack_revindex() for the new object, which
hits revindex_for_pack() for our new pack. It can't
find the packed_git in the revindex hash, and dies.
You could also replace the `repack` above with a push or
fetch to create a new pack, though these are less likely
(you would have to somehow learn about the new objects to
look them up).
Prior to 1a6d8b9 (do not discard revindex when re-preparing
packfiles, 2014-01-15), this was safe, as we threw away the
revindex whenever we re-scanned the pack directory (and thus
re-created the revindex hash on the fly). However, we don't
want to simply revert that commit, as it was solving a
different race.
So we have a few options:
- We can fix the race in 1a6d8b9 differently, by having
the bitmap code look in the revindex hash instead of
caching the pointer. But this would introduce a lot of
extra hash lookups for common bitmap operations.
- We could teach the revindex to dynamically add new packs
to the hash table. This would perform the same, but
would mean adding extra code to the revindex hash (which
currently cannot be resized at all).
- We can get rid of the hash table entirely. There is
exactly one revindex per pack, so we can just store it
in the packed_git struct. Since it's initialized lazily,
it does not add to the startup cost.
This is the best of both worlds: less code and fewer
hash table lookups. The original code likely avoided
this in the name of encapsulation. But the packed_git
and reverse_index code are fairly intimate already, so
it's not much of a loss.
This patch implements the final option. It's a minimal
conversion that retains the pack_revindex struct. No callers
need to change, and we can do further cleanup in a follow-on
patch.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-12-21 06:19:49 +00:00
|
|
|
* The pack index file is sorted by object name mapping to offset;
|
|
|
|
* this revindex array is a list of offset/index_nr pairs
|
2008-02-28 05:25:17 +00:00
|
|
|
* ordered by offset, so if you know the offset of an object, next offset
|
|
|
|
* is where its packed representation ends and the index_nr can be used to
|
|
|
|
* get the object sha1 from the main index.
|
|
|
|
*/
|
|
|
|
|
pack-revindex: radix-sort the revindex
The pack revindex stores the offsets of the objects in the
pack in sorted order, allowing us to easily find the on-disk
size of each object. To compute it, we populate an array
with the offsets from the sha1-sorted idx file, and then use
qsort to order it by offsets.
That does O(n log n) offset comparisons, and profiling shows
that we spend most of our time in cmp_offset. However, since
we are sorting on a simple off_t, we can use numeric sorts
that perform better. A radix sort can run in O(k*n), where k
is the number of "digits" in our number. For a 64-bit off_t,
using 16-bit "digits" gives us k=4.
On the linux.git repo, with about 3M objects to sort, this
yields a 400% speedup. Here are the best-of-five numbers for
running
echo HEAD | git cat-file --batch-check="%(objectsize:disk)
on a fully packed repository, which is dominated by time
spent building the pack revindex:
before after
real 0m0.834s 0m0.204s
user 0m0.788s 0m0.164s
sys 0m0.040s 0m0.036s
This matches our algorithmic expectations. log(3M) is ~21.5,
so a traditional sort is ~21.5n. Our radix sort runs in k*n,
where k is the number of radix digits. In the worst case,
this is k=4 for a 64-bit off_t, but we can quit early when
the largest value to be sorted is smaller. For any
repository under 4G, k=2. Our algorithm makes two passes
over the list per radix digit, so we end up with 4n. That
should yield ~5.3x speedup. We see 4x here; the difference
is probably due to the extra bucket book-keeping the radix
sort has to do.
On a smaller repo, the difference is less impressive, as
log(n) is smaller. For git.git, with 173K objects (but still
k=2), we see a 2.7x improvement:
before after
real 0m0.046s 0m0.017s
user 0m0.036s 0m0.012s
sys 0m0.008s 0m0.000s
On even tinier repos (e.g., a few hundred objects), the
speedup goes away entirely, as the small advantage of the
radix sort gets erased by the book-keeping costs (and at
those sizes, the cost to generate the the rev-index gets
lost in the noise anyway).
Signed-off-by: Jeff King <peff@peff.net>
Reviewed-by: Brandon Casey <drafnel@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-11 12:16:00 +00:00
|
|
|
/*
|
|
|
|
* This is a least-significant-digit radix sort.
|
|
|
|
*
|
|
|
|
* It sorts each of the "n" items in "entries" by its offset field. The "max"
|
|
|
|
* parameter must be at least as large as the largest offset in the array,
|
|
|
|
* and lets us quit the sort early.
|
|
|
|
*/
|
|
|
|
static void sort_revindex(struct revindex_entry *entries, unsigned n, off_t max)
|
2008-02-28 05:25:17 +00:00
|
|
|
{
|
pack-revindex: radix-sort the revindex
The pack revindex stores the offsets of the objects in the
pack in sorted order, allowing us to easily find the on-disk
size of each object. To compute it, we populate an array
with the offsets from the sha1-sorted idx file, and then use
qsort to order it by offsets.
That does O(n log n) offset comparisons, and profiling shows
that we spend most of our time in cmp_offset. However, since
we are sorting on a simple off_t, we can use numeric sorts
that perform better. A radix sort can run in O(k*n), where k
is the number of "digits" in our number. For a 64-bit off_t,
using 16-bit "digits" gives us k=4.
On the linux.git repo, with about 3M objects to sort, this
yields a 400% speedup. Here are the best-of-five numbers for
running
echo HEAD | git cat-file --batch-check="%(objectsize:disk)
on a fully packed repository, which is dominated by time
spent building the pack revindex:
before after
real 0m0.834s 0m0.204s
user 0m0.788s 0m0.164s
sys 0m0.040s 0m0.036s
This matches our algorithmic expectations. log(3M) is ~21.5,
so a traditional sort is ~21.5n. Our radix sort runs in k*n,
where k is the number of radix digits. In the worst case,
this is k=4 for a 64-bit off_t, but we can quit early when
the largest value to be sorted is smaller. For any
repository under 4G, k=2. Our algorithm makes two passes
over the list per radix digit, so we end up with 4n. That
should yield ~5.3x speedup. We see 4x here; the difference
is probably due to the extra bucket book-keeping the radix
sort has to do.
On a smaller repo, the difference is less impressive, as
log(n) is smaller. For git.git, with 173K objects (but still
k=2), we see a 2.7x improvement:
before after
real 0m0.046s 0m0.017s
user 0m0.036s 0m0.012s
sys 0m0.008s 0m0.000s
On even tinier repos (e.g., a few hundred objects), the
speedup goes away entirely, as the small advantage of the
radix sort gets erased by the book-keeping costs (and at
those sizes, the cost to generate the the rev-index gets
lost in the noise anyway).
Signed-off-by: Jeff King <peff@peff.net>
Reviewed-by: Brandon Casey <drafnel@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-11 12:16:00 +00:00
|
|
|
/*
|
|
|
|
* We use a "digit" size of 16 bits. That keeps our memory
|
|
|
|
* usage reasonable, and we can generally (for a 4G or smaller
|
|
|
|
* packfile) quit after two rounds of radix-sorting.
|
|
|
|
*/
|
|
|
|
#define DIGIT_SIZE (16)
|
|
|
|
#define BUCKETS (1 << DIGIT_SIZE)
|
|
|
|
/*
|
|
|
|
* We want to know the bucket that a[i] will go into when we are using
|
|
|
|
* the digit that is N bits from the (least significant) end.
|
|
|
|
*/
|
|
|
|
#define BUCKET_FOR(a, i, bits) (((a)[(i)].offset >> (bits)) & (BUCKETS-1))
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We need O(n) temporary storage. Rather than do an extra copy of the
|
|
|
|
* partial results into "entries", we sort back and forth between the
|
|
|
|
* real array and temporary storage. In each iteration of the loop, we
|
|
|
|
* keep track of them with alias pointers, always sorting from "from"
|
|
|
|
* to "to".
|
|
|
|
*/
|
2016-02-22 22:44:25 +00:00
|
|
|
struct revindex_entry *tmp, *from, *to;
|
pack-revindex: radix-sort the revindex
The pack revindex stores the offsets of the objects in the
pack in sorted order, allowing us to easily find the on-disk
size of each object. To compute it, we populate an array
with the offsets from the sha1-sorted idx file, and then use
qsort to order it by offsets.
That does O(n log n) offset comparisons, and profiling shows
that we spend most of our time in cmp_offset. However, since
we are sorting on a simple off_t, we can use numeric sorts
that perform better. A radix sort can run in O(k*n), where k
is the number of "digits" in our number. For a 64-bit off_t,
using 16-bit "digits" gives us k=4.
On the linux.git repo, with about 3M objects to sort, this
yields a 400% speedup. Here are the best-of-five numbers for
running
echo HEAD | git cat-file --batch-check="%(objectsize:disk)
on a fully packed repository, which is dominated by time
spent building the pack revindex:
before after
real 0m0.834s 0m0.204s
user 0m0.788s 0m0.164s
sys 0m0.040s 0m0.036s
This matches our algorithmic expectations. log(3M) is ~21.5,
so a traditional sort is ~21.5n. Our radix sort runs in k*n,
where k is the number of radix digits. In the worst case,
this is k=4 for a 64-bit off_t, but we can quit early when
the largest value to be sorted is smaller. For any
repository under 4G, k=2. Our algorithm makes two passes
over the list per radix digit, so we end up with 4n. That
should yield ~5.3x speedup. We see 4x here; the difference
is probably due to the extra bucket book-keeping the radix
sort has to do.
On a smaller repo, the difference is less impressive, as
log(n) is smaller. For git.git, with 173K objects (but still
k=2), we see a 2.7x improvement:
before after
real 0m0.046s 0m0.017s
user 0m0.036s 0m0.012s
sys 0m0.008s 0m0.000s
On even tinier repos (e.g., a few hundred objects), the
speedup goes away entirely, as the small advantage of the
radix sort gets erased by the book-keeping costs (and at
those sizes, the cost to generate the the rev-index gets
lost in the noise anyway).
Signed-off-by: Jeff King <peff@peff.net>
Reviewed-by: Brandon Casey <drafnel@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-11 12:16:00 +00:00
|
|
|
int bits;
|
2016-02-22 22:44:25 +00:00
|
|
|
unsigned *pos;
|
|
|
|
|
|
|
|
ALLOC_ARRAY(pos, BUCKETS);
|
|
|
|
ALLOC_ARRAY(tmp, n);
|
|
|
|
from = entries;
|
|
|
|
to = tmp;
|
pack-revindex: radix-sort the revindex
The pack revindex stores the offsets of the objects in the
pack in sorted order, allowing us to easily find the on-disk
size of each object. To compute it, we populate an array
with the offsets from the sha1-sorted idx file, and then use
qsort to order it by offsets.
That does O(n log n) offset comparisons, and profiling shows
that we spend most of our time in cmp_offset. However, since
we are sorting on a simple off_t, we can use numeric sorts
that perform better. A radix sort can run in O(k*n), where k
is the number of "digits" in our number. For a 64-bit off_t,
using 16-bit "digits" gives us k=4.
On the linux.git repo, with about 3M objects to sort, this
yields a 400% speedup. Here are the best-of-five numbers for
running
echo HEAD | git cat-file --batch-check="%(objectsize:disk)
on a fully packed repository, which is dominated by time
spent building the pack revindex:
before after
real 0m0.834s 0m0.204s
user 0m0.788s 0m0.164s
sys 0m0.040s 0m0.036s
This matches our algorithmic expectations. log(3M) is ~21.5,
so a traditional sort is ~21.5n. Our radix sort runs in k*n,
where k is the number of radix digits. In the worst case,
this is k=4 for a 64-bit off_t, but we can quit early when
the largest value to be sorted is smaller. For any
repository under 4G, k=2. Our algorithm makes two passes
over the list per radix digit, so we end up with 4n. That
should yield ~5.3x speedup. We see 4x here; the difference
is probably due to the extra bucket book-keeping the radix
sort has to do.
On a smaller repo, the difference is less impressive, as
log(n) is smaller. For git.git, with 173K objects (but still
k=2), we see a 2.7x improvement:
before after
real 0m0.046s 0m0.017s
user 0m0.036s 0m0.012s
sys 0m0.008s 0m0.000s
On even tinier repos (e.g., a few hundred objects), the
speedup goes away entirely, as the small advantage of the
radix sort gets erased by the book-keeping costs (and at
those sizes, the cost to generate the the rev-index gets
lost in the noise anyway).
Signed-off-by: Jeff King <peff@peff.net>
Reviewed-by: Brandon Casey <drafnel@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-11 12:16:00 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* If (max >> bits) is zero, then we know that the radix digit we are
|
|
|
|
* on (and any higher) will be zero for all entries, and our loop will
|
|
|
|
* be a no-op, as everybody lands in the same zero-th bucket.
|
|
|
|
*/
|
|
|
|
for (bits = 0; max >> bits; bits += DIGIT_SIZE) {
|
|
|
|
unsigned i;
|
|
|
|
|
|
|
|
memset(pos, 0, BUCKETS * sizeof(*pos));
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We want pos[i] to store the index of the last element that
|
|
|
|
* will go in bucket "i" (actually one past the last element).
|
|
|
|
* To do this, we first count the items that will go in each
|
|
|
|
* bucket, which gives us a relative offset from the last
|
|
|
|
* bucket. We can then cumulatively add the index from the
|
|
|
|
* previous bucket to get the true index.
|
|
|
|
*/
|
|
|
|
for (i = 0; i < n; i++)
|
|
|
|
pos[BUCKET_FOR(from, i, bits)]++;
|
|
|
|
for (i = 1; i < BUCKETS; i++)
|
|
|
|
pos[i] += pos[i-1];
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Now we can drop the elements into their correct buckets (in
|
|
|
|
* our temporary array). We iterate the pos counter backwards
|
|
|
|
* to avoid using an extra index to count up. And since we are
|
|
|
|
* going backwards there, we must also go backwards through the
|
|
|
|
* array itself, to keep the sort stable.
|
|
|
|
*
|
|
|
|
* Note that we use an unsigned iterator to make sure we can
|
|
|
|
* handle 2^32-1 objects, even on a 32-bit system. But this
|
|
|
|
* means we cannot use the more obvious "i >= 0" loop condition
|
|
|
|
* for counting backwards, and must instead check for
|
|
|
|
* wrap-around with UINT_MAX.
|
|
|
|
*/
|
|
|
|
for (i = n - 1; i != UINT_MAX; i--)
|
|
|
|
to[--pos[BUCKET_FOR(from, i, bits)]] = from[i];
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Now "to" contains the most sorted list, so we swap "from" and
|
|
|
|
* "to" for the next iteration.
|
|
|
|
*/
|
2017-01-28 21:40:58 +00:00
|
|
|
SWAP(from, to);
|
pack-revindex: radix-sort the revindex
The pack revindex stores the offsets of the objects in the
pack in sorted order, allowing us to easily find the on-disk
size of each object. To compute it, we populate an array
with the offsets from the sha1-sorted idx file, and then use
qsort to order it by offsets.
That does O(n log n) offset comparisons, and profiling shows
that we spend most of our time in cmp_offset. However, since
we are sorting on a simple off_t, we can use numeric sorts
that perform better. A radix sort can run in O(k*n), where k
is the number of "digits" in our number. For a 64-bit off_t,
using 16-bit "digits" gives us k=4.
On the linux.git repo, with about 3M objects to sort, this
yields a 400% speedup. Here are the best-of-five numbers for
running
echo HEAD | git cat-file --batch-check="%(objectsize:disk)
on a fully packed repository, which is dominated by time
spent building the pack revindex:
before after
real 0m0.834s 0m0.204s
user 0m0.788s 0m0.164s
sys 0m0.040s 0m0.036s
This matches our algorithmic expectations. log(3M) is ~21.5,
so a traditional sort is ~21.5n. Our radix sort runs in k*n,
where k is the number of radix digits. In the worst case,
this is k=4 for a 64-bit off_t, but we can quit early when
the largest value to be sorted is smaller. For any
repository under 4G, k=2. Our algorithm makes two passes
over the list per radix digit, so we end up with 4n. That
should yield ~5.3x speedup. We see 4x here; the difference
is probably due to the extra bucket book-keeping the radix
sort has to do.
On a smaller repo, the difference is less impressive, as
log(n) is smaller. For git.git, with 173K objects (but still
k=2), we see a 2.7x improvement:
before after
real 0m0.046s 0m0.017s
user 0m0.036s 0m0.012s
sys 0m0.008s 0m0.000s
On even tinier repos (e.g., a few hundred objects), the
speedup goes away entirely, as the small advantage of the
radix sort gets erased by the book-keeping costs (and at
those sizes, the cost to generate the the rev-index gets
lost in the noise anyway).
Signed-off-by: Jeff King <peff@peff.net>
Reviewed-by: Brandon Casey <drafnel@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-11 12:16:00 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If we ended with our data in the original array, great. If not,
|
|
|
|
* we have to move it back from the temporary storage.
|
|
|
|
*/
|
|
|
|
if (from != entries)
|
2016-09-25 07:24:03 +00:00
|
|
|
COPY_ARRAY(entries, tmp, n);
|
pack-revindex: radix-sort the revindex
The pack revindex stores the offsets of the objects in the
pack in sorted order, allowing us to easily find the on-disk
size of each object. To compute it, we populate an array
with the offsets from the sha1-sorted idx file, and then use
qsort to order it by offsets.
That does O(n log n) offset comparisons, and profiling shows
that we spend most of our time in cmp_offset. However, since
we are sorting on a simple off_t, we can use numeric sorts
that perform better. A radix sort can run in O(k*n), where k
is the number of "digits" in our number. For a 64-bit off_t,
using 16-bit "digits" gives us k=4.
On the linux.git repo, with about 3M objects to sort, this
yields a 400% speedup. Here are the best-of-five numbers for
running
echo HEAD | git cat-file --batch-check="%(objectsize:disk)
on a fully packed repository, which is dominated by time
spent building the pack revindex:
before after
real 0m0.834s 0m0.204s
user 0m0.788s 0m0.164s
sys 0m0.040s 0m0.036s
This matches our algorithmic expectations. log(3M) is ~21.5,
so a traditional sort is ~21.5n. Our radix sort runs in k*n,
where k is the number of radix digits. In the worst case,
this is k=4 for a 64-bit off_t, but we can quit early when
the largest value to be sorted is smaller. For any
repository under 4G, k=2. Our algorithm makes two passes
over the list per radix digit, so we end up with 4n. That
should yield ~5.3x speedup. We see 4x here; the difference
is probably due to the extra bucket book-keeping the radix
sort has to do.
On a smaller repo, the difference is less impressive, as
log(n) is smaller. For git.git, with 173K objects (but still
k=2), we see a 2.7x improvement:
before after
real 0m0.046s 0m0.017s
user 0m0.036s 0m0.012s
sys 0m0.008s 0m0.000s
On even tinier repos (e.g., a few hundred objects), the
speedup goes away entirely, as the small advantage of the
radix sort gets erased by the book-keeping costs (and at
those sizes, the cost to generate the the rev-index gets
lost in the noise anyway).
Signed-off-by: Jeff King <peff@peff.net>
Reviewed-by: Brandon Casey <drafnel@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-11 12:16:00 +00:00
|
|
|
free(tmp);
|
|
|
|
free(pos);
|
|
|
|
|
|
|
|
#undef BUCKET_FOR
|
|
|
|
#undef BUCKETS
|
|
|
|
#undef DIGIT_SIZE
|
2008-02-28 05:25:17 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Ordered list of offsets of objects in the pack.
|
|
|
|
*/
|
2015-12-21 06:20:33 +00:00
|
|
|
static void create_pack_revindex(struct packed_git *p)
|
2008-02-28 05:25:17 +00:00
|
|
|
{
|
2013-07-10 11:50:26 +00:00
|
|
|
unsigned num_ent = p->num_objects;
|
|
|
|
unsigned i;
|
2008-02-28 05:25:17 +00:00
|
|
|
const char *index = p->index_data;
|
|
|
|
|
2016-02-26 21:37:16 +00:00
|
|
|
ALLOC_ARRAY(p->revindex, num_ent + 1);
|
2008-02-28 05:25:17 +00:00
|
|
|
index += 4 * 256;
|
|
|
|
|
|
|
|
if (p->index_version > 1) {
|
|
|
|
const uint32_t *off_32 =
|
|
|
|
(uint32_t *)(index + 8 + p->num_objects * (20 + 4));
|
|
|
|
const uint32_t *off_64 = off_32 + p->num_objects;
|
|
|
|
for (i = 0; i < num_ent; i++) {
|
|
|
|
uint32_t off = ntohl(*off_32++);
|
|
|
|
if (!(off & 0x80000000)) {
|
2015-12-21 06:20:33 +00:00
|
|
|
p->revindex[i].offset = off;
|
2008-02-28 05:25:17 +00:00
|
|
|
} else {
|
2018-01-17 19:08:23 +00:00
|
|
|
p->revindex[i].offset = get_be64(off_64);
|
|
|
|
off_64 += 2;
|
2008-02-28 05:25:17 +00:00
|
|
|
}
|
2015-12-21 06:20:33 +00:00
|
|
|
p->revindex[i].nr = i;
|
2008-02-28 05:25:17 +00:00
|
|
|
}
|
|
|
|
} else {
|
|
|
|
for (i = 0; i < num_ent; i++) {
|
|
|
|
uint32_t hl = *((uint32_t *)(index + 24 * i));
|
2015-12-21 06:20:33 +00:00
|
|
|
p->revindex[i].offset = ntohl(hl);
|
|
|
|
p->revindex[i].nr = i;
|
2008-02-28 05:25:17 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* This knows the pack format -- the 20-byte trailer
|
|
|
|
* follows immediately after the last object data.
|
|
|
|
*/
|
2015-12-21 06:20:33 +00:00
|
|
|
p->revindex[num_ent].offset = p->pack_size - 20;
|
|
|
|
p->revindex[num_ent].nr = -1;
|
|
|
|
sort_revindex(p->revindex, num_ent, p->pack_size);
|
2008-02-28 05:25:17 +00:00
|
|
|
}
|
|
|
|
|
2015-12-21 06:20:33 +00:00
|
|
|
void load_pack_revindex(struct packed_git *p)
|
2008-02-28 05:25:17 +00:00
|
|
|
{
|
2015-12-21 06:20:33 +00:00
|
|
|
if (!p->revindex)
|
|
|
|
create_pack_revindex(p);
|
2013-10-24 18:00:36 +00:00
|
|
|
}
|
|
|
|
|
2015-12-21 06:20:33 +00:00
|
|
|
int find_revindex_position(struct packed_git *p, off_t ofs)
|
2013-10-24 18:00:36 +00:00
|
|
|
{
|
|
|
|
int lo = 0;
|
2015-12-21 06:20:33 +00:00
|
|
|
int hi = p->num_objects + 1;
|
|
|
|
struct revindex_entry *revindex = p->revindex;
|
2013-10-24 18:00:36 +00:00
|
|
|
|
2008-02-28 05:25:17 +00:00
|
|
|
do {
|
2013-07-10 11:50:26 +00:00
|
|
|
unsigned mi = lo + (hi - lo) / 2;
|
2008-02-28 05:25:17 +00:00
|
|
|
if (revindex[mi].offset == ofs) {
|
2013-10-24 18:00:36 +00:00
|
|
|
return mi;
|
2008-02-28 05:25:17 +00:00
|
|
|
} else if (ofs < revindex[mi].offset)
|
|
|
|
hi = mi;
|
|
|
|
else
|
|
|
|
lo = mi + 1;
|
|
|
|
} while (lo < hi);
|
2013-10-24 18:00:36 +00:00
|
|
|
|
2008-10-29 23:02:49 +00:00
|
|
|
error("bad offset for revindex");
|
2013-10-24 18:00:36 +00:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
struct revindex_entry *find_pack_revindex(struct packed_git *p, off_t ofs)
|
|
|
|
{
|
2015-12-21 06:20:33 +00:00
|
|
|
int pos;
|
|
|
|
|
|
|
|
load_pack_revindex(p);
|
|
|
|
pos = find_revindex_position(p, ofs);
|
2013-10-24 18:00:36 +00:00
|
|
|
|
|
|
|
if (pos < 0)
|
|
|
|
return NULL;
|
|
|
|
|
2015-12-21 06:20:33 +00:00
|
|
|
return p->revindex + pos;
|
2008-02-28 05:25:17 +00:00
|
|
|
}
|