Complete.Org: Mailing Lists: Archives: freeciv-dev: August 2001:
[Freeciv-Dev] Re: Map coordinate cleanups.
Home

[Freeciv-Dev] Re: Map coordinate cleanups.

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: rf13@xxxxxxxxxxxxxxxxxxxxxx
Cc: Kevin Brown <kevin@xxxxxxxxxxxxxx>, Vasco Alexandre Da Silva Costa <vasc@xxxxxxxxxxxxxx>, freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: Map coordinate cleanups.
From: "Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx>
Date: Sun, 19 Aug 2001 13:04:39 -0400

The total run times for an exactly identical game show an overall
25% cost (9 min vs 12 min) for functions over macros for a small
set of the common ones. One could probably refine this by playing
with the set to see which were the key ones.

My thoughts at the moment are that this would be really useful for 
client code that seems to have a performance bottleneck in processing
server packets that can cause it to die from buffer exhaustion. A
small speedup in the client might be enough to keep it ahead of the 
wave.

Cheers,
RossW

At 03:36 PM 01/08/19 +0200, Raimar Falke wrote:
>On Fri, Aug 17, 2001 at 09:28:16PM -0700, Kevin Brown wrote:
>> Vasco Alexandre Da Silva Costa <vasc@xxxxxxxxxxxxxx> wrote:
>> > On Fri, 17 Aug 2001, Kevin Brown wrote:
>> [...]
>> > A one line function doesn't have much a compiler can optimize. If the
code
>> > is inlined the compiler may do optimizations by using neighbouring code
>> > values and so on to speed things up. And you have no function call
>> > overhead. You could say this increases code size. I say that all the
>> > context saving and restoring and function call probably have more
>> > instruction than the function itself.
>> 
>> I'm not even arguing for substituting functions for one-line macros!
>> That would be silly: the macro is more concise in that case, so it
>> wins on most counts.  What's at issue here are the complicated macros
>> that would, IMO, be better expressed in a function, but which are made
>> macros for performance reasons.  For these, I'm of the opinion that
>> there's no substitute for testing.  If a function is a more
>> appropriate expression but there are concerns about performance then
>> the inline form of the function should be tested against the macro
>> form in the working code.  If the difference favors the macro
>> significantly enough then you go with the macro, else go with the
>> function.
>
>Ok this were enough technical arguments. Has anybody looked at the
>numbers? You can't get profile data of method which just got turned
>into a macro. But the calling time of calling method can be used to
>measure improvements.
>
>       Raimar
>
>-- 
> email: rf13@xxxxxxxxxxxxxxxxx
>  This customer comes into the computer store. "I'm looking for a mystery
>  Adventure Game with lots of graphics. You know, something realy
>  challenging". "Well," replied the clerk, "have you tried Windows 98 ?"




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