On 12/04/2014 09:29 AM, Stefan Beller wrote:
Somewhat short commit message, especially the motivation is missing.
What do we gain with this patch ?
In the struct the compiler needs to layout 2*20 bytes for the sha's.
It follows an int, typically 4 bytes.
It follows another int, now with one bit.
Then we have the pointer "struct ref_lock *lock",
which needs to be aligned on 4 byte boundary for a 32 bit processor,
or an 8 byte boundary for a 64 bit machine.
Our "1 bit int" is padded with 31 bits.
We do not gain anything in memory consumption. (unless we declare int flags
to be 31 bits, and the compiler may join "have_old" and "flags" together
into one int in memory.
But there is a price to pay:
The generated code to fiddle out the bits from an int becomes more complicated.
You need to fetch the memory from one int, mask and shift.
Some processors can do this, out of my mind some ARM can, some can not.
We need to run the compiler to look at the generated code of course.
> Signed-off-by: Stefan Beller <sbeller@xxxxxxxxxx>
> ---
>
> Notes:
> Also a patch, which hasn't been posted on the mailing list before.
>
> refs.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/refs.c b/refs.c
> index b54b5b3..2942227 100644
> --- a/refs.c
> +++ b/refs.c
> @@ -3532,7 +3532,7 @@ struct ref_update {
> unsigned char new_sha1[20];
> unsigned char old_sha1[20];
> int flags; /* REF_NODEREF? */
> - int have_old; /* 1 if old_sha1 is valid, 0 otherwise */
> + int have_old:1; /* 1 if old_sha1 is valid, 0 otherwise */
> struct ref_lock *lock;
> int type;
> char *msg;
>
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html