[Top][All Lists]
[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."