Complete.Org: Mailing Lists: Archives: freeciv-dev: June 2004:
[Freeciv-Dev] Re: (PR#8982) City.c cleanup
Home

[Freeciv-Dev] Re: (PR#8982) City.c cleanup

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: pim@xxxxxxxxxxxx
Subject: [Freeciv-Dev] Re: (PR#8982) City.c cleanup
From: "Jason Short" <jdorje@xxxxxxxxxxxxxxxxxxxxx>
Date: Thu, 17 Jun 2004 13:48:57 -0700
Reply-to: rt@xxxxxxxxxxx

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

rwetmore@xxxxxxxxxxxx wrote:

>>>I'm not sure that changing arbitrary static functions to inline is a
>>>good idea.
> 
> Changing things to inline was discussed, shown to be a bad thing with no 
> real redeeming features beyond performance degradation and has thus been 
> preferentially adopted as usual :-).

We're not talking about changing macros to inline.  We're talking about 
changing non-inline functions to inline.

>>Now, why does freeciv run slower with my patch? No, it does not have
>>anything to do with inline, since it runs even slower without it... Does
>>const give slower code??
> 
> Changing things to function calls adds enormous performance degradation, 
> only partially and occasionally recovered by inlining since this is now an 
> optional compiler element. If you want performance (no longer true it 
> appears), then you need to use real "C" elements like macros that give 
> guaranteed results. You also need to understand when some constructs are 
> being treated as static or const and what the difference is in the code 
> optimization context that you are destroying in ways similar to inlining.

Per didn't change anything to a function call.  He merely added "const" 
modifiers to parameters of existing functions.  Evidently this does slow 
down execution, under his compiler anyway.  You'd probably have to look 
at a disassembler to find out why.

jason




[Prev in Thread] Current Thread [Next in Thread]