NetNews Usenet Archive 1993 #3/NN_1993_3.iso/spool/comp/lang/c/20162

Internet Message Format | 1993-01-21 | 1.7 KB

Xref: sparky comp.lang.c:20162 comp.lang.c++:19853
Newsgroups: comp.lang.c,comp.lang.c++
Path: sparky!uunet!mole-end!mat
From: [e-mail]
Subject: Re: C/C++ Correctness (was: Re: C/C++ Speed)
Message-ID: <[e-mail]>
Summary: On space, speed, and inline
Organization: :
References: <[e-mail]> <1jka6h$[e-mail]> <[e-mail]>
Date: Mon, 25 Jan 1993 01:43:32 GMT
Lines: 25

In article <[e-mail]>, [e-mail] (Eric Smith) writes:

> Inlining can in fact make C++ faster than C, especially if it's the
> only non-C feature you use in C++.  For many C programmers, inlining
> alone is enough to justify the move to C++.

> The way to make inlining effective is to use it carefully, and only
> inline the most critical speed sensitive functions.  If you inline
> functions that don't really need it, you pay a penalty in size of your
> executable program, which can also cause virtual memory paging, which
> can slow the whole program down and defeat the whole purpose of
> inlining.  ...

Remember though, that sufficiently small functions (e.g. members that
set or return a single member variable, nonmembers like  operator+  on
a type like  complex,  etc.) will be small enough on almost all machines
that they will not make the code larger, will improve locality, avoid
function call overhead, perhaps provide opportunities for local optimization
where global would otherwise be necessary--and these are what inlines
are most often used for.
--
 (This man's opinions are his own.)
 From mole-end                Mark Terribile

 [e-mail], Somewhere in Matawan, NJ