[Freeciv-Dev] Re: (PR#7195) inlining map_pos_to_index

["rwetmore@xxxxxxxxxxxx" <rwetmore@xxxxxxxxxxxx>]

<URL: http://rt.freeciv.org/Ticket/Display.html?id=7195 >

As usual you have argued your case by getting the statements completely
backwards.

Jason Short wrote:
> <URL: http://rt.freeciv.org/Ticket/Display.html?id=7195 >
> 
> rwetmore@xxxxxxxxxxxx wrote:
> 
>><URL: http://rt.freeciv.org/Ticket/Display.html?id=7195 >
>>
>>
>>Since inline functions are always less effective than macros, what is the
>>performance *loss* by going from the previous macro form to the inline one.
>>What is the justification for making the change from macro to inline given
>>all the inherent problems with inline not shared by macros?
> 
> The inline function is faster in this case because it takes advantage of 
> temporary variables and thus only has to do about two-thirds of the work 
> that the macro does.  This is also why it's shorter.

This is not a problem as macros can use temp variables as well. If you
compare apples and oranges your comparisons don't mean much.

> Besides being able to use temp variables, inline functions have other 
> advantages:
> 
> - Use loops and other complex constructs while retaining a *functional* 
> macro.

In general, if one is using loops then this is probably too complicated for
the kinds of performance optimizations these techniques should be used for.
But note, *only* when a macro is restricted to expression syntax to return
a functional value is this a concern.

There is a strong move to use void * functions in Freeciv code and remove the
return status and need to check it. Programming with exceptions, or passing
return values through the argument list are two ways macros can accomplish
any value return operation. Thus there is no limitation in practice unless
you also insist on a particular coding style.

In a few cases, inline may appear to have a stylistic advantage here, but the
majority of other cases far outweigh this one limited case.

> - Resolve parameters just once (at the start of the function) rather 
> than every time they are used in the macro.  This makes things faster 
> and avoids potential bugs.

Again, this is not a problem with macros, just how you code them. Good
macro code will always be as good or better than inline. This is because
macro code is as fully optimized as all other code, whereas inline code
is often subjected to a number of other constraints by using different
compiler code and its functional characteristics.

> - Better type checking of parameters.

Again, this is not a problem. There are solutions to fully typecheck
macro arguments if you want to implement them.

> - More readible header files.  Function declarations and implementations 
> are separated.

I disagree. I think macros are as readable as inline functions and often
moreso as you can run the preprocessor to dump out the "C" code to know
exactly what is being produced. With Inline you never really know what is
being done to the code.

> The only drawback is that the optimized code *may* be slower in some 
> cases for some compilers.

Since the reason for using inline is purportedly performance, then this
would seem to be the only one that counts.

But clearly it is far from the only drawback to inline. So you entire
argument just took a pretty major credibility hit with this statement.

> Personally I would prefer functions (inline or not) in all cases over 
> macros.  But I'm not religious about it.
> 
> jason

This is the choice made by O-O languages that sacrifice performance for
various other features. That is why they are so slow in comparison and
why even limited help such as inlining is used in those cases.

But in "C" you have a preprocessor that is far better for handling the
performance and API definition problems. To not use it is a mistake, and
the result will be slower more cumbersome "C" code.


I actually prefer O-O programming, but rewriting Freeciv 2.0 in an O-O
language which is the proper way to go about this, has long been rejected
by the maintainer community. If one chooses to develop in "C", then one
should adhere to the choice and use the full set of "C" tools and
advantages.

Cheers,
RossW
=====