grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] save around 100 bytes on core.img by inlining small misc.c f


From: Robert Millan
Subject: Re: [PATCH] save around 100 bytes on core.img by inlining small misc.c functions
Date: Wed, 19 Aug 2009 17:11:23 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

On Mon, Aug 17, 2009 at 03:54:06PM +0200, Vladimir 'phcoder' Serbinenko wrote:
> On Mon, Aug 17, 2009 at 3:43 PM, Robert Millan<address@hidden> wrote:
> > On Sat, Aug 15, 2009 at 04:47:32PM +0200, Vladimir 'phcoder' Serbinenko 
> > wrote:
> >> +static inline char *
> >> +grub_strncat (char *dest, const char *src, int c)
> >> +{
> >> +  char *p = dest;
> >> +
> >> +  while (*p)
> >> +    p++;
> >> +
> >> +  while ((*p = *src) != '\0' && c--)
> >> +    {
> >> +      p++;
> >> +      src++;
> >> +    }
> >> +
> >> +  *p = '\0';
> >> +
> >> +  return dest;
> >> +}
> >
> > Some of them (like this one) are surprisingly big.  Did you test them
> > separately?
> Yes I did. My test environment was a core.img with pc+fat+biosdisk. I
> have a log which functions save how much. In this case inlining
> strncat saved 21 bytes. The reason for some bigger functions to be
> inlined is that they are used only in non-size critical parts. In this
> case it's used in LUA and iso9660.mod (one call). So inlining strncat
> always saves space (even if iso9660.mod is in core.img but there is no
> size limit when booting from cd).

Ok, fine with me then.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."




reply via email to

[Prev in Thread] Current Thread [Next in Thread]