blob | da357479cf19aad4bebc64f874c76fdf8566712b |

4 /*

5 * Conventional binary search loop looks like this:

6 *

7 * unsigned lo, hi;

8 * do {

9 * unsigned mi = (lo + hi) / 2;

10 * int cmp = "entry pointed at by mi" minus "target";

11 * if (!cmp)

12 * return (mi is the wanted one)

13 * if (cmp > 0)

14 * hi = mi; "mi is larger than target"

15 * else

16 * lo = mi+1; "mi is smaller than target"

17 * } while (lo < hi);

18 *

19 * The invariants are:

20 *

21 * - When entering the loop, lo points at a slot that is never

22 * above the target (it could be at the target), hi points at a

23 * slot that is guaranteed to be above the target (it can never

24 * be at the target).

25 *

26 * - We find a point 'mi' between lo and hi (mi could be the same

27 * as lo, but never can be as same as hi), and check if it hits

28 * the target. There are three cases:

29 *

30 * - if it is a hit, we are happy.

31 *

32 * - if it is strictly higher than the target, we set it to hi,

33 * and repeat the search.

34 *

35 * - if it is strictly lower than the target, we update lo to

36 * one slot after it, because we allow lo to be at the target.

37 *

38 * If the loop exits, there is no matching entry.

39 *

40 * When choosing 'mi', we do not have to take the "middle" but

41 * anywhere in between lo and hi, as long as lo <= mi < hi is

42 * satisfied. When we somehow know that the distance between the

43 * target and lo is much shorter than the target and hi, we could

44 * pick mi that is much closer to lo than the midway.

45 *

46 * Now, we can take advantage of the fact that SHA-1 is a good hash

47 * function, and as long as there are enough entries in the table, we

48 * can expect uniform distribution. An entry that begins with for

49 * example "deadbeef..." is much likely to appear much later than in

50 * the midway of the table. It can reasonably be expected to be near

51 * 87% (222/256) from the top of the table.

52 *

53 * However, we do not want to pick "mi" too precisely. If the entry at

54 * the 87% in the above example turns out to be higher than the target

55 * we are looking for, we would end up narrowing the search space down

56 * only by 13%, instead of 50% we would get if we did a simple binary

57 * search. So we would want to hedge our bets by being less aggressive.

58 *

59 * The table at "table" holds at least "nr" entries of "elem_size"

60 * bytes each. Each entry has the SHA-1 key at "key_offset". The

61 * table is sorted by the SHA-1 key of the entries. The caller wants

62 * to find the entry with "key", and knows that the entry at "lo" is

63 * not higher than the entry it is looking for, and that the entry at

64 * "hi" is higher than the entry it is looking for.

65 */

71 {

85 else

102 /*

103 * byte 0 thru (ofs-1) are the same between

104 * lo and hi; ofs is the first byte that is

105 * different.

106 */

114 }

120 }

128 /*

129 * Even if we know the target is much closer to 'hi'

130 * than 'lo', if we pick too precisely and overshoot

131 * (e.g. when we know 'mi' is closer to 'hi' than to

132 * 'lo', pick 'mi' that is higher than the target), we

133 * end up narrowing the search space by a smaller

134 * amount (i.e. the distance between 'mi' and 'hi')

135 * than what we would have (i.e. about half of 'lo'

136 * and 'hi'). Hedge our bets to pick 'mi' less

137 * aggressively, i.e. make 'mi' a bit closer to the

138 * middle than we would otherwise pick.

139 */

143 kyv++;

145 kyv--;

146 }

153 }

168 }

171 }