From: Junio C Hamano <gitster@pobox•com>
To: Jeff King <peff@peff•net>
Cc: Ted Ts'o <tytso@mit•edu>, git@vger•kernel.org
Subject: Re: jk/tag-contains: stalled
Date: Thu, 05 Aug 2010 13:53:05 -0700 [thread overview]
Message-ID: <7vd3twdbny.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <20100805190653.GA2942@sigill> (Jeff King's message of "Thu\, 5 Aug 2010 15\:06\:54 -0400")
Jeff King <peff@peff•net> writes:
> Oops, thanks, I had forgotten that the marks needed to be addressed.
> Should I be introducing new flags? We have 27 flag bits, but I would
> hate to waste 2 of them.
In the longer term it would be not just nice but necessary for us to come
up with a scheme where different codepaths can "allocate bits from object
flags", without having to fear stepping on each other's toes. Some
possible approaches off the top of my head are:
- Extend "struct object" by another uint64_t to give it 64 more bits?
That would make the minimum object size from 24 bytes to 32 bytes and
during a pack-object session we would keep a lot of objects (not just
commits but trees and blobs) in core, so we probably would not want to
do this.
- Extend "struct commit" by another uint32_t? Currently a "struct
commit" is 72 bytes on x86_64 (there is an unfortunate 4-byte padding
gap between indegree and date), and 48 bytes on i386 and this would
enlarge the latter to 52 bytes (this comes free on 64-bit archs).
As we need a lot more bits on commits than on other objects
(e.g. left-right do not need to be placed on trees or blobs), this
approach might be more space efficient.
- Use one bit in the current flags section to signal "extended flag bits
present on this object", and have a separate hashtable for minority
objects that have that bit set? This would work only for flag bits
that are rarely used (otherwise the secondary hashtable will be full of
objects and per-object overhead will kill us).
- Migrate some users of flag bits that only mark small miniroty of
commits to use dedicated hashtable to free their bits [*1*]. I don't
know if there are candidates for doing this offhand. Just uttering it
as an idea.
Independent of this issue, I suspect that we might want to fold
object.used into the general set of flags---it is only used by fsck as far
as I remember.
[Footnote]
*1* Also we would want to do something similar to the commit.util field so
that more than one utility libraries can attach their own stuff to each
commit. It _might_ make sense to instead get rid of commit.util and
migrate the users to a separate "one object hash per one type of info",
though. In any case it is a separate topic.
next prev parent reply other threads:[~2010-08-05 20:53 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-04 22:24 What's cooking in git.git (Aug 2010, #01; Wed, 4) Junio C Hamano
2010-08-05 0:16 ` jk/tag-contains: stalled Ted Ts'o
2010-08-05 16:29 ` Junio C Hamano
2010-08-05 17:05 ` Junio C Hamano
2010-08-05 17:36 ` Jeff King
2010-08-05 18:47 ` Junio C Hamano
2010-08-05 19:06 ` Jeff King
2010-08-05 19:18 ` Jay Soffian
2010-08-05 19:27 ` Jeff King
2010-08-05 20:00 ` Jay Soffian
2010-08-05 20:36 ` Ted Ts'o
2010-08-05 20:53 ` Junio C Hamano [this message]
2010-08-05 21:38 ` Thomas Rast
2010-08-05 22:15 ` Junio C Hamano
2010-08-06 5:44 ` Junio C Hamano
2010-08-05 6:53 ` tc/checkout-B Jonathan Nieder
2010-08-05 10:18 ` tc/checkout-B Tay Ray Chuan
2010-08-05 8:20 ` What's cooking in git.git (Aug 2010, #01; Wed, 4) Matthieu Moy
2010-08-05 8:22 ` [PATCH 1/5] diff: parse separate options like -S foo Matthieu Moy
2010-08-05 12:16 ` Jakub Narebski
2010-08-05 12:24 ` Matthieu Moy
2010-08-05 8:22 ` [PATCH 2/5] diff: split off a function for --stat-* option parsing Matthieu Moy
2010-08-05 8:22 ` [PATCH 3/5] diff: parse separate options --stat-width n, --stat-name-width n Matthieu Moy
2010-08-05 8:22 ` [PATCH 4/5] log: parse separate options like git log --grep foo Matthieu Moy
2010-08-05 8:22 ` [PATCH 5/5] log: parse separate option for --glob Matthieu Moy
2010-08-05 11:41 ` mm/shortopt-detached Jonathan Nieder
2010-08-05 21:12 ` jc/sha1-name-find-fix Dmitry V. Levin
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=7vd3twdbny.fsf@alter.siamese.dyndns.org \
--to=gitster@pobox$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=peff@peff$(echo .)net \
--cc=tytso@mit$(echo .)edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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