Nguyễn Thái Ngọc Duy <pclouds@xxxxxxxxx> writes: > For each object in the input pack, we need one struct object_entry. On > x86-64, this struct is 64 bytes long. Although: > > - The 8 bytes for delta_depth and base_object_no are only useful when > show_stat is set. And it's never set unless someone is debugging. > > - The three fields hdr_size, type and real_type take 4 bytes each > even though they never use more than 4 bits. > > By moving delta_depth and base_object_no out of struct object_entry > and make the other 3 fields one byte long instead of 4, we shrink 25% > of this struct. > > On a 3.4M object repo that's about 53MB. The saving is less impressive > compared to index-pack total memory use (about 400MB before delta > resolving, so the saving is just 13%) > > Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@xxxxxxxxx> > --- > I'm not sure if this patch is worth pursuing. It makes the code a > little bit harder to read. I was just wondering how much memory could > be saved.. I would say 13% is already impressive ;-). I do not find the result all that harder to read. I however think that the change would make it a lot harder to maintain, especially because the name "object-entry-extra" does not have any direct link to "show-stat" to hint us that this must be allocated when show-stat is in use and must never be looked at when show-stat is not in use. Also it makes me wonder if the compilers are smart enough to notice that the codepaths that access objects_extra[] are OK because they are all inside "if (show_stat)". -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html