Re: [dev] [sbase][patch] find: change execv to execvp

From: Dimitris Papastamos <sin_AT_2f30.org>
Date: Sat, 21 Feb 2015 13:38:47 +0000

On Sat, Feb 21, 2015 at 02:05:23PM +0100, FRIGN wrote:
> On Sat, 21 Feb 2015 09:55:53 +0100
> k0ga_AT_shike2.com wrote:
>
> > > char *name; /* string representation of op */
> > > - int type; /* from Tok.type */
> > > - int prec; /* precedence */
> > > - int nargs; /* number of arguments (unary or binary) */
> > > - int lassoc; /* left associative */
> > > + char type; /* from Tok.type */
> > > + char prec; /* precedence */
> > > + char nargs; /* number of arguments (unary or binary) */
> > > + char lassoc; /* left associative */
> > > } Op_info;
> >
> > I don't have any problem with the patch, but the advantage of this
> > patch depends too much of which machine you are using. In a
> > i386/x86-64 the code is going to be similar and you are going to save
> > memory, but in other processors maybe you need aditional operations to
> > transform the char (which can be signed or unsigned) to integer. I
> > usually put flags as integers because you don't save too much
> > (if you have four options like this case) and you don't know if the
> > code is going to be smaller or not.
>
> It all comes down to alignment:
>
> For 32 Bit / 64 Bit machines (assuming int is 32 bit and char is 8 bit).
> Signed, unsigned makes no difference, assuming self-aligned (which is the
> case on x86, x86_64 and ARM):
>
> OLD
> char *name; /* 4 bytes */ /* 8 bytes */
> int type; /* 4 bytes */ /* 4 bytes */
> int prec; /* 4 bytes */ /* 4 bytes */
> int nargs; /* 4 bytes */ /* 4 bytes */
> int lassoc; /* 4 bytes */ /* 4 bytes */
> -----------------------------------------
> 24 bytes 28 bytes
>
> NEW
> char *name; /* 4 bytes */ /* 8 bytes */
> char type; /* 1 byte */ /* 1 byte */
> char prec; /* 1 byte */ /* 1 byte */
> char nargs; /* 1 byte */ /* 1 byte */
> char lassoc; /* 1 byte */ /* 1 byte */
> -----------------------------------------
> 8 bytes 12 bytes
>
> You would only get padding-issues when mixing ints and chars, or putting
> the pointer somewhere else than the beginning (because pointer-alignment
> has to be in effect. ints have to be 4 byte-aligned, so an int following
> a pointer-aligned char would have 3 bytes of padding inbetween.
> But there is no problem here. char's are fine, but I didn't look too deep
> into the code.
> The reason why often chars have no advantage over ints is exactly when
> ints and chars are mixed, given they both need 4 bytes of memory at the
> end of the day.

Yeah that's all good but at the end of the day this kind of optimization
only makes sense if you have a lot of these objects allocated. You can
significantly reduce the memory footprint in that case. This is not the
case here so it doesn't quite matter. I am OK either way.

Cheers,
Dimitris
Received on Sat Feb 21 2015 - 14:38:47 CET