From: Duy Nguyen <pclouds@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: "brian m. carlson" <sandals@crustytoothpaste.net>,
Michael Haggerty <mhagger@alum.mit.edu>,
"Kyle J. McKay" <mackyle@gmail.com>,
Git Mailing List <git@vger.kernel.org>,
Andreas Schwab <schwab@linux-m68k.org>
Subject: Re: [PATCH v2 01/10] Define a structure for object IDs.
Date: Sun, 15 Mar 2015 07:17:07 +0700 [thread overview]
Message-ID: <CACsJy8CK=0QpsMpZKN6Js99xFRD6mpJW1id2BBQDMsV1DaHiPg@mail.gmail.com> (raw)
In-Reply-To: <xmqqbnjvw7c8.fsf@gitster.dls.corp.google.com>
On Sun, Mar 15, 2015 at 5:19 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Duy Nguyen <pclouds@gmail.com> writes:
>
>>> 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?
Notice that the first time pack->obj[] is filled using
lookup_object(). So yes, the hash table has all the pointers that
pack->obj[] has. If somebody wants to remove an object out of hash
table, then all pack->obj[] are invalidated, but I don't think we ever
delete objects from hash table.
--
Duy
next prev parent reply other threads:[~2015-03-15 0:17 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-07 23:23 [PATCH v2 00/10] Use a structure for object IDs brian m. carlson
2015-03-07 23:23 ` [PATCH v2 01/10] Define " brian m. carlson
[not found] ` <CEA07500-9F47-4B24-AD5D-1423A601A4DD@gmail.com>
2015-03-11 22:08 ` brian m. carlson
2015-03-12 0:26 ` Junio C Hamano
2015-03-12 9:34 ` brian m. carlson
2015-03-12 10:28 ` Michael Haggerty
2015-03-12 10:46 ` brian m. carlson
2015-03-12 11:16 ` Duy Nguyen
2015-03-12 18:24 ` Junio C Hamano
2015-03-12 18:44 ` Junio C Hamano
2015-03-13 0:58 ` Duy Nguyen
2015-03-13 6:03 ` Junio C Hamano
2015-03-14 11:49 ` Duy Nguyen
2015-03-14 22:19 ` Junio C Hamano
2015-03-15 0:17 ` Duy Nguyen [this message]
2015-03-15 2:32 ` Junio C Hamano
2015-03-07 23:23 ` [PATCH v2 02/10] Define utility functions " brian m. carlson
2015-03-08 9:57 ` Duy Nguyen
2015-03-08 14:48 ` brian m. carlson
2015-03-11 12:44 ` Michael Haggerty
2015-03-07 23:23 ` [PATCH v2 03/10] bisect.c: convert leaf functions to use struct object_id brian m. carlson
2015-03-07 23:23 ` [PATCH v2 04/10] archive.c: convert " brian m. carlson
2015-03-11 14:20 ` Michael Haggerty
2015-03-11 22:12 ` brian m. carlson
2015-03-07 23:24 ` [PATCH v2 05/10] zip: use GIT_SHA1_HEXSZ for trailers brian m. carlson
2015-03-07 23:24 ` [PATCH v2 06/10] bulk-checkin.c: convert to use struct object_id brian m. carlson
2015-03-07 23:24 ` [PATCH v2 07/10] diff: convert struct combine_diff_path to object_id brian m. carlson
2015-03-07 23:24 ` [PATCH v2 08/10] commit: convert parts to struct object_id brian m. carlson
2015-03-11 14:46 ` Michael Haggerty
2015-03-07 23:24 ` [PATCH v2 09/10] patch-id: convert to use " brian m. carlson
2015-03-07 23:24 ` [PATCH v2 10/10] apply: convert threeway_stage to object_id brian m. carlson
2015-03-08 7:43 ` [PATCH v2 00/10] Use a structure for object IDs Junio C Hamano
2015-03-11 2:38 ` Kyle J. McKay
2015-03-11 16:08 ` Michael Haggerty
2015-03-11 20:35 ` Junio C Hamano
2015-03-13 22:45 ` brian m. carlson
-- strict thread matches above, loose matches on Subject: below --
2015-03-13 23:39 brian m. carlson
2015-03-13 23:39 ` [PATCH v2 01/10] Define " brian m. carlson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CACsJy8CK=0QpsMpZKN6Js99xFRD6mpJW1id2BBQDMsV1DaHiPg@mail.gmail.com' \
--to=pclouds@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=mackyle@gmail.com \
--cc=mhagger@alum.mit.edu \
--cc=sandals@crustytoothpaste.net \
--cc=schwab@linux-m68k.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).