Re: Why are ref_lists sorted?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Julian Phillips <julian@xxxxxxxxxxxxxxxxx> writes:

> So my questions are:
>
> 1) what have I broken by removing the sort?

See do_for_each_ref().  We walk packed and loose refs in
parallel, preferring loose ref if exists (so that after packing,
updating a ref does not have to remove entry from packed-refs
file).

> 2) is it worth trying to optimise the sort?

If you have 9,000 entries, it probably is worth doing.  Also you
might want to use an expanding array of pointers instead of
linked list.

Currently add_ref() is shared between packed and loose refs, and
the order loose refs are discovered depends on readdir() order,
so we cannot do without sorting on that side.  But I suspect
reading them in in the order they are discovered and then
sorting at the end just once might be a good thing to do.

If we write packed refs _after_ sorting, we should be able to
optimize on the side that reads packed-refs even better.  As you
read one new line from the file, you make sure that it sorts
later than the last entry you saw, and append to the end of
list; if you find an unorderd entry, remember that the list is
not sorted, and sort at the very end after reading all the refs.

Or something like that...





-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]