From: Karsten Blees <karsten.blees@gmail.com>
To: Thomas Rast <tr@thomasrast.ch>
Cc: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: What's cooking in git.git (Dec 2013, #02; Fri, 6)
Date: Mon, 09 Dec 2013 15:03:28 +0100 [thread overview]
Message-ID: <52A5CDB0.2020206@gmail.com> (raw)
In-Reply-To: <87lhzvhceb.fsf@linux-1gf2.Speedport_W723_V_Typ_A_1_00_098>
Am 08.12.2013 11:20, schrieb Thomas Rast:
> Karsten Blees <karsten.blees@gmail.com> writes:
>
>> Am 07.12.2013 23:23, schrieb Thomas Rast:
>>> Karsten Blees <karsten.blees@gmail.com> writes:
>>>
>>>> Extending 'struct hashmap_entry' with an int-sized member shouldn't waste
>>>> memory on 64-bit systems. This is already documented in api-hashmap.txt,
>>>> but needs '__attribute__((__packed__))' to work. Reduces e.g.
>>>
>>> You'd have to guard __attribute__((__packed__)) with some compiler
>>> detection in git-compat-util.h though.
>>>
>>
>> Isn't that already handled? __attribute__ is already widely used
>> (e.g. for printf formats), and platforms that don't support it define
>> it as empty (e.g. MSVC). Or do you mean I should account for
>> compiler-specific variants (#pragma pack...)?
>
> True, __attribute__ expands to nothing on unknown compilers, but what
> does the compiler do when it sees an unknown attribute? If some of them
> choke, you need a separate macro.
>
> I'm a bit confused myself though, many attributes have special macros in
> git-compat-util.h but others we just use in the code.
>
So what do you propose? I basically see three options:
1.) Trial and error
GCC supports __packed__ as of 2.3 (1992), so any other compilers that copied the __attribute__ feature probably won't complain.
2.) Accept the wasted memory
Moving the hash code from the hash table (as in hash.[ch]) to the entry is already a big improvement, as it no longer multiplies hash code + wasted bytes with the load factor. 64-bit software uses more memory in general, so we could just live with it (and only fix the documentation in api-hashmap.txt).
3.) Inject individual fields via macro
Instead of injecting a struct hashmap_entry, which implies alignment to sizeof(struct hashmap_entry), we could inject the individual fields, e.g.
#define HASHMAP_ENTRY_HEADER struct hashmap_entry __next; unsinged int __hash;
struct name_entry {
HASHMAP_ENTRY_HEADER
int namelen;
char *name;
};
What do you think?
Karsten
next prev parent reply other threads:[~2013-12-09 14:03 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-06 23:52 What's cooking in git.git (Dec 2013, #02; Fri, 6) Junio C Hamano
2013-12-07 10:03 ` Felipe Contreras
2013-12-07 20:30 ` Felipe Contreras
2013-12-09 21:00 ` Junio C Hamano
2013-12-07 17:03 ` Thomas Rast
2013-12-09 22:33 ` Jeff King
2013-12-09 22:51 ` Junio C Hamano
2013-12-07 18:49 ` Matthieu Moy
2013-12-07 19:56 ` Karsten Blees
2013-12-07 22:23 ` Thomas Rast
2013-12-07 22:32 ` Karsten Blees
2013-12-08 10:20 ` Thomas Rast
2013-12-09 14:03 ` Karsten Blees [this message]
2013-12-09 20:08 ` Jonathan Nieder
2013-12-09 23:19 ` Karsten Blees
2013-12-09 23:45 ` Jonathan Nieder
2013-12-18 13:10 ` Karsten Blees
2013-12-18 14:05 ` Karsten Blees
2013-12-18 14:12 ` Karsten Blees
2013-12-09 17:43 ` Junio C Hamano
2013-12-09 17:48 ` Junio C Hamano
2013-12-18 13:41 ` [PATCH] hashmap.h: Use 'unsigned int' for hash-codes everywhere Karsten Blees
2013-12-18 17:46 ` Junio C Hamano
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=52A5CDB0.2020206@gmail.com \
--to=karsten.blees@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=tr@thomasrast.ch \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.