On Tue, Jun 21, 2022 at 02:52:53PM +0530, Abhradeep Chakraborty wrote: > Taylor Blau <me@xxxxxxxxxxxx> wrote: > > I remember we had a brief off-list discussion about whether we should > > store the full object IDs in the offset table, or whether we could store > > their pack- or index-relative ordering. Is there a reason to prefer one > > or the other? > > > > I don't think we need to explain the choice fully in the documentation > > in this patch, but it may be worth thinking about separately > > nonetheless. We can store either order and convert it to an object ID in > > constant time. > > > > To figure out which is best, I would recommend trying a few different > > choices here and seeing how they do or don't impact your performance > > testing. > > I think at that time I thought it would add extra cost of computing > the actual commit ids from those index position. So, I didn't go > further here. It should be negligible relative to everything else, I would imagine. The function that converts an index position into an object ID is `nth_packed_object_id()`. > I still have a feeling that there is some way to get rid of this > list of commit ids. But at the same time, I do not want to add > extra computation to the code. I'm hoping that the additional complexity is minor. And if we can save some extra bytes that aren't necessary in the first place without compromising on performance, I think that's worthwhile to do. Thanks, Taylor
