[Freeciv-Dev] Re: Profiling Civserver again

["Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx>]

Attached is a quick hack of my accumulated macro patches into map.c, map.h
for yesterday's CVS.

My server seems to be running fine. It has been running 5-10 minutes and
is into the 1700's with a 7 AI roster. 

The bloodshed looks interesting from a quick peek at the savegames via
civworld :-). Ok, its done. The Finns cleaned up on the two main continents,
but 3 of the other factions held them off on their own.

Note, I would not personally reccommend adding these changes to 1.12.0
without a lot more scrutiny and test runs, but if Paul(?) wants to run 
them against the current profiling benchmark, I would be quite interested.
Caveat, they were designed more for coding ease, e.g. breakable single loop
coding style, and things like dual x,y and xy indexing.

The real advantage is probably when you go through a lot of the current 
code and replace the index computations with loop variables, i.e. replace 
MAP(x,y) with a MAP1(_xy) or the equivalent to avoid the endemic 
map.xsize*y+x on every access using base loop variables x,y.

Cheers,
RossW
=====

At 06:16 PM 01/07/29 -0400, Ross W. Wetmore wrote:
>Double underbar as in "__blort" is reserved to the OS headers which you can
>verify by looking in /usr/include.
>
>No user code is supposed to use single underbars "_FOOlish" for variable
>names, so they are "safe" in user header macros.
>
>Be careful of overlapping macro arguments, i.e. passing an _x0 arg into
>another
>macro, but usually you can even get away with namespace collisions between
>macros. However, users that peek and use the _variables within the begin
>and end blocks of the current split macro flavour do so at their own risk,
>i.e. should be careful to check that there isn't an overriding local
>context due to nesting. 
>
>Some of the current map.h macros actually have code in the end blocks, i.e.
>the user or another macro could unintentionally modify things in dangerous
>ways. It is slightly safer to try to put all the internal stuff in a single
>block at the start where no one can get at it at least for one iteration
>block sequence, and on a new iteration there is usually only a subset of
>local variables that are dangerous.
>
>The mapgen.c examples from a couple emails ago tried to follow these
>published and unpublished standards.
>
>Cheers,
>RossW
>=====

map_patch.gz
Description: Binary data