On Sat, Mar 17, 2018 at 8:53 PM, Ævar Arnfjörð Bjarmason <ava...@gmail.com> wrote: > > On Sat, Mar 17 2018, Nguyễn Thái Ngọc Duy jotted: > >> Previous patches leave lots of holes and padding in this struct. This >> patch reorders the members and shrinks the struct down to 80 bytes >> (from 136 bytes, before any field shrinking is done) with 16 bits to >> spare (and a couple more in in_pack_header_size when we really run out >> of bits). > > Given what I mentioned in 87po42cwql....@evledraar.gmail.com just now I > think we should add this to the commit message. > > This is the last in a series of memory reduction patches (see > "pack-objects: a bit of document about struct object_entry" for the > first one). > > Overall they've reduced repack memory size on linux.git from 3.747G > to 3.424G, or by around 320M, a decrease of 8.5%. The runtime of > repack has stayed the same throughout this series. Ævar's testing on > a big monorepo he has access to (bigger than linux.git) has shown a > 7.9% reduction, so the overall expected improvement should be > somewhere around 8%. > > See 87po42cwql....@evledraar.gmail.com on-list > (https://public-inbox.org/git/87po42cwql....@evledraar.gmail.com/) > for more detailed numbers and a test script used to produce the > numbers cited above.
Yeah. I probably should add something that was on my mind but never written out. These shrinking and packing definitely slow down access to these struct members (more instructions to read or write). However, since pack-objects is mostly IO-bound, and when it's CPU-bound, I think the hot path is either inflating objects or generating deltas, these slowdowns do not matter (and smaller cache footprint helps too) -- Duy
