On Mon, Jul 26, 2010 at 11:53 AM, Paul Eggert <egg...@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.
