Complete.Org: Mailing Lists: Archives: freeciv-dev: July 2001:
[Freeciv-Dev] Re: Profiling Civserver again
Home

[Freeciv-Dev] Re: Profiling Civserver again

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
Cc: freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: Profiling Civserver again
From: Jason Dorje Short <jshort@xxxxxxxxxxxxx>
Date: Tue, 31 Jul 2001 15:05:16 -0400

Paul Zastoupil wrote:
> 
> Once more with today's cvs:
> http://civserver.freeciv.org/~paulz/gprof-current.txt
> 
> Compare to:
> previous cvs http://civserver.freeciv.org/~paulz/gprof-O2-42.txt
> jason's bare patch http://civserver.freeciv.org/~paulz/gprof-patched-O2-42.txt

Several notes:

1.  The current CVS has some extra assertions that the original "bare"
patch didn't have, so a slightly decreased performance would be expected
if compiled with debugging.

2.  The behavior of all three sets of code should (probably) be the
same, but is not!  The function map_get_tile is called within
really_generate_warmap 83,054,722 times in both original CVS and my bare
patch.  In current CVS, it is different.  Most likely this is due to
changes elsewhere in CVS???

The numbers are promising.  If we trust a single test [1], current CVS
performs 6% faster than old CVS - and the code is cleaner besides [2]. 
If compiled without debugging, the savings may be closer to the 8% seen
in my original patch.

[1] Although the game should run identically, I don't know how much
error gprof has in measurement.  Probably it is very small.

[2] At least, it will be once the iteration macro is used in more than
one place.  This should wait until after 1.12.0.

Another big bottleneck is map_get_tile.  This is called 300 million
times over the course of the game, accounting for 8% of server time. 
However, I'm not sure if there's a good way to make it faster _and also_
cleaner.  Making it a macro would make things much faster.  Another
point of note is that on each and every call it normalizes the map pos,
even though for most calls this is already known.  Introducing a second
function/macro, map_get_normal_tile(x, y) would give some savings here
(you'd still want to assert that the tile was normal), but I don't see
an advantage otherwise.

Also, I think cleaning up map_adjust_x should do good things.  Here we
make the code both faster and cleaner.

jason


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