]> git.ipfire.org Git - thirdparty/git.git/commit - refs.c
ref_array: keep track of whether references are sorted
authorMichael Haggerty <mhagger@alum.mit.edu>
Tue, 17 Jan 2012 05:50:32 +0000 (06:50 +0100)
committerJunio C Hamano <gitster@pobox.com>
Tue, 17 Jan 2012 19:53:21 +0000 (11:53 -0800)
commite6ed3ca651fac702f9d9a9ef64a14c7efadf7365
treebc8b11199c60eca41babff239491e792adcbedcb
parente45a59955ec78bca12930bcf6aa9642fd94c9e7c
ref_array: keep track of whether references are sorted

Keep track of how many entries at the beginning of a ref_array are already
sorted.  In sort_ref_array(), return early if the the array is already
sorted (i.e., if no new references has been appended to the end of the
list since the last call to sort_ref_array()).

Sort ref_arrays only when needed, namely in search_ref_array() and in
do_for_each_ref().  However, never call sort_ref_array() on the
extra_refs, because extra_refs can contain multiple entries with the same
name and because sort_ref_array() not only sorts, but de-dups its
contents.

This change is currently not useful, because entries are not added to
ref_arrays after they are created.  But in a moment they will be...

Implementation note: we could store a binary "sorted" value instead of
an integer, but storing the number of sorted entries leaves the way
open for a couple of possible future optimizations:

* In sort_ref_array(), sort *only* the unsorted entries, then merge
  them with the sorted entries.  This should be faster if most of the
  entries are already sorted.

* Teach search_ref_array() to do a binary search of any sorted
  entries, and if unsuccessful do a linear search of any unsorted
  entries.  This would avoid the need to sort the list every time that
  search_ref_array() is called, and (given some intelligence about how
  often to sort) could significantly improve the speed in certain
  hypothetical usage patterns.

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
refs.c