Re: [HACKERS] inlining

>
> Bruce Momjian wrote:
> >
> > >
> > > Bruce Momjian wrote:
> > > >
> > > > Let me add, I am not inlining all the functions, but only the top part
> > > > of them that deals with cachoffsets and nulls.  These are the easy ones,
> > > > and the ones that get used most often.
> > >
> > > fastgetattr() is called from a HUNDREDS places - I'm not sure that
> > > this is good idea.
> >
> > Here is the fastgetattr macro.  Again, I just inlined the cacheoffset
> > and null handlling at the top.  Doesn't look like much code, though the
> > ?: macro format makes it look larger.  What do you think?
>
> Try to gmake clean and gmake... Please compare old/new sizes for
> debug version too.

OK, here it is, 'size' with two regression run timings:

OLD
    text    data    bss    dec    hex
    831488    155648    201524    1188660    122334
      151.12 real         4.66 user         8.52 sys
      141.70 real         1.28 user         7.44 sys

NEW
    text    data    bss    dec    hex
    864256    155648    201548    1221452    12a34c
      143.52 real         3.48 user         9.08 sys
      146.10 real         1.34 user         7.44 sys

These numbers are with assert and -g on.

Interesting that the 1st regression test is the greatest, and the 2nd is
the least, with the same no-inlining, but with standard optimizations.

Now, my test of startup times shows it saves 0.015 seconds on a 0.10
second test.  This 0.015 is the equvalent to the fork() overhead time.
This speedup is reproducable.

The inlining is a 3% increase in size, but provides a 15% speed increase
on my startup test.

Looks good to me.  I am going to apply the patch, and let people tell me
if they see a speedup worth a 3% binary size increase.

The only visible change is that heap_getattr() does not take a buffer
parameter anymore, thanks to the removal of time travel.

Vadim, I will send you the patch separately to look at.

--
Bruce Momjian
maillist@candle.pha.pa.us