> Hyman Rosen wrote:
> > Once you have profiled your code and determined that a
> > particular virtual call is the problem, and at the call
> > site you know what class you actually have,

alain@miniussi.net (Alain Miniussi) wrote
> This looks like the argument usually made for inline, which
> calls for some comments, since there is a lot of pratice with
> inline::
>  - It might be interesting to notice that if that rule was
> as popular as it's claimed, then we would have an inline-like
> keyword for the call site (inline *this* call if *this* call
> is the problem), instead of just one for the declaration (inline
> *all* calls if *this* call is the problem). Your solution
> does not follow common practice for inline, not sure if it
> is good or bad, but if you want to adapt the inline "official"
> guideline to this problem, you do not get the result you
> are describing.

That's a darn good point. Wouldn't it make sense to add syntax
requesting that THIS ONE CALL be inlined, if possible?

When the called function is trivial, it usually makes sense to declare
it always inline. For instance, if a class has an accessor function that
simply returns a simple expression, the code generated for a function
call can actually be both shorter and faster than the code generated to
call a function. In such cases, it makes perfect sense to ALWAYS inline
the function.

Conversely, when the called function is very large and complex, most (all?)
compilers will ignore the inline declaration anyway.

But for medium-size functions, we have the classic tradeoff -- making
the function inline will make the program faster, but also bigger. In
such functions, it might make perfect sense to default to call, but allow
individual call sites the option to call it inline (provided, of course,
that the definition is visible).

    int foo(int a, int b) {
       int t=b;
       // Some nonsense algorithm... details unimportant...
       // The point here is, it's more complex than "return a+b"
       // but far less complex than "generate a sales report"
       for (int c=1; c<=a; ++c) t*=(a+c*c);
       return t;
    }

    // Another meaningless algorithm...
    // The point is, it calls foo() three times.
    // Inlining would not help this function significantly.
    int short_calc() {
        // This isn't in a tight loop -- just call normally
        return foo(2,3) + foo(3,2) + foo(1,0);
    }

    // Another meaningless algorithm...
    // The point is, it calls foo() 600 million times from inside
    // a highly-nested loop.
    // Inlining would save the cost of 600 million function calls.
    int long_calc() {
        int t=0;
        for (int a1=1; a1<30000; ++a1)
            for (int a2=1; a2<20000; ++a2)
               // Inside tight nested loop; let's inline the call to foo
               t=inline foo(a1+a2,t); // Syntax not relevant
        return t;
    }

As before, "inline" would still be a recommendation -- the compiler would
be free to ignore it.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]