From: Jeff King <peff@peff.net>
To: Sverre Rabbelier <srabbelier@gmail.com>
Cc: "Jonathan Nieder" <jrnieder@gmail.com>,
git@vger.kernel.org, "Junio C Hamano" <gitster@pobox.com>,
"Jakub Narebski" <jnareb@gmail.com>, "Ted Ts'o" <tytso@mit.edu>,
"Ævar Arnfjörð" <avarab@gmail.com>,
"Clemens Buchacher" <drizzd@aon.at>,
"Shawn O. Pearce" <spearce@spearce.org>,
"David Barr" <davidbarr@google.com>
Subject: Re: [PATCH 2/3] fast-export: use object to uint32 map instead of "decorate"
Date: Fri, 15 Jul 2011 16:00:44 -0400 [thread overview]
Message-ID: <20110715200044.GB356@sigill.intra.peff.net> (raw)
In-Reply-To: <CAGdFq_guf8fa014t17KyNoEzpCAK-aG5BrpQ40tQ=1507OJ8bw@mail.gmail.com>
On Fri, Jul 15, 2011 at 11:40:02AM +0200, Sverre Rabbelier wrote:
> On Thu, Jul 14, 2011 at 19:52, Jeff King <peff@peff.net> wrote:
> > Previously we encoded the "mark" mapping inside the "void *"
> > field of a "struct decorate". It's a little more natural for
> > us to do so using a data structure made for holding actual
> > values.
> >
> > Signed-off-by: Jeff King <peff@peff.net>
> > ---
> > And this is an example of use. It doesn't save all that much code, but I
> > think it's a little more natural. It can also save some bytes of the hash
> > value in each entry if your pointers are larger than 32-bit.
>
> Did you run any benchmarks on this?
No, I didn't. I expect it to be exactly the same on x86_64. We save
32-bits of pointer space, but the generality I mentioned in patch 1
wastes 32-bits of space for the "used" flag. So it evens out,
space-wise.
The time complexity should be exactly the same (the macro definitions
are more or less the exact decorate code, but with the types
parameterized, so the generated code should be the same).
But I'm not sure this code is going to end up used, anyway. It looks
like we might add a generation header after all.
-Peff
next prev parent reply other threads:[~2011-07-15 20:00 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-13 6:47 [RFC/PATCHv2 0/6] generation numbers for faster traversals Jeff King
2011-07-13 6:57 ` [RFC/PATCHv2 1/6] decorate: allow storing values instead of pointers Jeff King
2011-07-13 17:52 ` Jonathan Nieder
2011-07-13 20:08 ` Jeff King
2011-07-14 17:34 ` Jeff King
2011-07-14 17:51 ` [PATCH 1/3] implement generic key/value map Jeff King
2011-07-14 18:52 ` Bert Wesarg
2011-07-14 18:54 ` Bert Wesarg
2011-07-14 18:55 ` Jeff King
2011-07-14 19:07 ` Bert Wesarg
2011-07-14 19:14 ` Jeff King
2011-07-14 19:18 ` Bert Wesarg
2011-07-14 17:52 ` [PATCH 2/3] fast-export: use object to uint32 map instead of "decorate" Jeff King
2011-07-15 9:40 ` Sverre Rabbelier
2011-07-15 20:00 ` Jeff King [this message]
2011-07-14 17:53 ` [PATCH 3/3] decorate: use "map" for the underlying implementation Jeff King
2011-07-14 21:06 ` [RFC/PATCHv2 1/6] decorate: allow storing values instead of pointers Junio C Hamano
2011-08-04 22:43 ` [RFC/PATCH 0/5] macro-based key/value maps Jeff King
2011-08-04 22:45 ` [PATCH 1/5] implement generic key/value map Jeff King
2011-08-04 22:46 ` [PATCH 2/5] fast-export: use object to uint32 map instead of "decorate" Jeff King
2011-08-04 22:46 ` [PATCH 3/5] decorate: use "map" for the underlying implementation Jeff King
2011-08-04 22:46 ` [PATCH 4/5] map: implement persistent maps Jeff King
2011-08-04 22:46 ` [PATCH 5/5] implement metadata cache subsystem Jeff King
2011-08-04 22:48 ` [RFC/PATCH 0/2] patch-id caching Jeff King
2011-08-04 22:49 ` [PATCH 1/2] cherry: read default config Jeff King
2011-08-04 22:49 ` [PATCH 2/2] cache patch ids on disk Jeff King
2011-08-04 22:52 ` Jeff King
2011-08-05 11:03 ` [RFC/PATCH 0/5] macro-based key/value maps Jeff King
2011-08-05 15:31 ` René Scharfe
2011-08-06 6:30 ` Jeff King
2011-07-13 7:04 ` [RFC/PATCHv2 2/6] add metadata-cache infrastructure Jeff King
2011-07-13 8:18 ` Bert Wesarg
2011-07-13 8:31 ` Jeff King
2011-07-13 8:45 ` Bert Wesarg
2011-07-13 19:18 ` Jeff King
2011-07-13 19:40 ` Junio C Hamano
2011-07-13 19:33 ` Junio C Hamano
2011-07-13 20:25 ` Jeff King
2011-07-13 7:05 ` [RFC/PATCHv2 3/6] commit: add commit_generation function Jeff King
2011-07-13 14:26 ` Eric Sunshine
2011-07-13 7:05 ` [RFC/PATCHv2 4/6] pretty: support %G to show the generation number of a commit Jeff King
2011-07-13 7:06 ` [RFC/PATCHv2 5/6] check commit generation cache validity against grafts Jeff King
2011-07-13 14:26 ` Eric Sunshine
2011-07-13 19:35 ` Jeff King
2011-07-13 7:06 ` [RFC/PATCHv2 6/6] limit "contains" traversals based on commit generation Jeff King
2011-07-13 7:23 ` Jeff King
2011-07-13 20:33 ` Junio C Hamano
2011-07-13 20:58 ` Jeff King
2011-07-13 21:12 ` Junio C Hamano
2011-07-13 21:18 ` Jeff King
2011-07-15 18:22 ` Junio C Hamano
2011-07-15 20:40 ` Jeff King
2011-07-15 21:04 ` Junio C Hamano
2011-07-15 21:14 ` Jeff King
2011-07-15 21:01 ` Generation numbers and replacement objects Jakub Narebski
2011-07-15 21:10 ` Jeff King
2011-07-16 21:10 ` Jakub Narebski
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=20110715200044.GB356@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=avarab@gmail.com \
--cc=davidbarr@google.com \
--cc=drizzd@aon.at \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jnareb@gmail.com \
--cc=jrnieder@gmail.com \
--cc=spearce@spearce.org \
--cc=srabbelier@gmail.com \
--cc=tytso@mit.edu \
/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).