[prev in list] [next in list] [prev in thread] [next in thread] 

List:       coreutils-bug
Subject:    bug#6734: "inline" overused in .c files?
From:       Chen Guo <chen.guo.0625 () gmail ! com>
Date:       2010-07-27 4:29:33
Message-ID: AANLkTinGFHqNTwRadi00TzavH2LiZGdXG3k=KeBEa-uU () mail ! gmail ! com
[Download RAW message or body]

On Mon, Jul 26, 2010 at 11:53 AM, Paul Eggert <eggert@cs.ucla.edu> wrote:
> I noticed thirteen "inline"s in coreutils/src/sort.c.  Just for fun, I
> removed them all.  In ten cases, removing "inline" made no difference to
> the generated machine code on my platform (RHEL 5, x86-64, GCC 4.1.2,
> compiled with the typical gcc -O2).  In the three sort.c functions
> that were exceptions (queue_insert, write_unique, check_insert),
> removing "inline" made the overall code a tad shorter with no
> measurable change to CPU performance.
>
> Is there a reason those "inline"s are in there?  If not, I'm inclined
> to remove them.  I can see a use for "static inline" in .h files, as
> this asks the compiler not to warn about unused functions, but as far
> as I know, it's typically not necessary to use "inline" in .c files
> these days, as the compiler is typically smart enough.
>
> I've checked this only for coreutils/src/sort.c but perhaps the same
> argument applies to other source files in coreutils or other GNU apps, so
> I'll CC: this to bug-gnulib for more-general comment.
>

It's interesting that the three that are different are all from the new patch...

I can't think of a reason off the top of my head why we chose to inline them;
they are all short functions that are called _very_ often in our algorithm, and
that's the most likely reason why we inlined them.

I also recall a small bump in performance with at least write_unique, but that
could have just been a blip from testing on a shared machine.




[prev in list] [next in list] [prev in thread] [next in thread]