Re: [PATCH v2 01/10] Define a structure for object IDs.
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Mar 14, 2015, 22:19 UTC
- Message-ID
- <xmqqbnjvw7c8.fsf@gitster.dls.corp.google.com>
- In-Reply-To
- <CACsJy8BeFO3RQJ6pU5+q6E4n3A36X9PgYoi7xB_NQ4C_JYaP5w@mail.gmail.com>
Duy Nguyen <pclouds@gmail.com> writes:
Show 12 quoted lines
>> Anyway, wouldn't this be all academic? I do not see how you would >> keep the object name in the <pack, nth> format in-core, as the >> obj_hash[] is a hashtable keyed by <sha-1>, and even when we switch >> to a different hash, I cannot see how such a table to ensure the >> singleton-ness of in-core objects can be keyed sometimes by <hash> >> and by <pack, nth> in some other time. > > I'm implementing something to see how much we gain by avoiding object > lookup. The current approach is having "struct object ** obj" in > "struct packed_git", indexed by "nth". So when you have <pack, nth> > and pack->obj[nth] is valid, you'll get to "struct object *" without > hashing.
But do you realize that the hashtable serves two purposes? Grab the object from its name is one thing, and the other one I am not seeing how you will make it work with "sometimes <sha-1> sometimes <pack,nth>" is to ensure that we will have only one in-core copy for the same object. We even walk the hashtable when we want to drop the flag bits from all in-core objects, so even if you instanciated an in-core object without going through the object name layer, the hashtable needs to have a pointer to such a pointer, no?