Re: [PATCH v7 06/13] pack-objects: move in_pack out of struct object_entry

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

 



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.



[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]

  Powered by Linux