On Sat, Mar 24 2018, Nguyễn Thái Ngọc Duy wrote: > Instead of using 8 bytes (on 64 bit arch) to store a pointer to a > pack. Use an index instead since the number of packs should be > relatively small. > > This limits the number of packs we can handle to 1k. Since we can't be > sure people can never run into the situation where they have more than > 1k pack files. Provide a fall back route for it. > > If we find out they have too many packs, the new in_pack_by_idx[] > array (which has at most 1k elements) will not be used. Instead we > allocate in_pack[] array that holds nr_objects elements. This is > similar to how the optional in_pack_pos field is handled. > > The new simple test is just to make sure the too-many-packs code path > is at least executed. The true test is running > > make test GIT_TEST_FULL_IN_PACK_ARRAY=1 Aside from the tiny nit in 87efk9yfm2.fsf@xxxxxxxxxxxxxxxxxxx this looks good to me. I've tested this with the same method noted in 87vadpxv27.fsf@xxxxxxxxxxxxxxxxxxx against the version before it on similar test data, and got: * Reduction in user time by 0.42% * Reduction in system time by 3.17% * Reduction in RSS by 0.003209% * Reduction in page faults by 0% & 0.006539% (time(1) reports two different numbers) * Reduction in the I of I/O by 99.504132% (note: from 4840 bytes to 24 bytes, so some fluke...) * Reduction in the O of I/O by 0% I.e. there's no notable change at all, but I thought it would be useful to re-run this for context.
