[Freeciv-Dev] Re: somebody fix struct *player! (was: FoW remove player bug)

[Thue Janus Kristensen <thue@xxxxxxx>]

On Wed, 17 May 2000, Thue Janus Kristensen wrote:
> On Wed, 17 May 2000, Jules Bean wrote:
> > On Wed, May 17, 2000 at 03:36:11PM +0200, Thue Janus Kristensen wrote:
> > > Just a note: I am going to apply a patch that makes some functions that
> > > access bitvectors in maphand.c use playerid instead of struct player
> > > *pplayer.
> > > 
> > > This should be done as it is a waste of CPU to extract the player number
> > > (index in the bitvectors) from player struct each time the functions are
> > > called. (and it is called a lot)
> > 
> > This is probably a great idea for clean code, but I'd just like to
> > point out that the CPU argument is bogus ;-) The time to dereference a
> > pointer is a single cycle, (assuming it's in a cache) and that's just
> > not going to stack up compared to the path-finding code which we all
> > suspect is the current bottleneck.
> > 
> > Optimisations like this are good for programmer efficiency and code
> > simplicity, but it's not where we're going to find performance
> > increases...
> 
> But if dereferncing means that it has to load the player struct into
> cache it makes a bigger difference.
> The pathfinding takes a long time because it checks a large number of
> tiles. In each of these checks a part is accesing these bitvectors, so I
> would think it could make a difference.
> 
> Btw; maybe these oneilne functions like map_get_know() should be made into
> macros to avoid the overhead of a function call; is the saving worth it?
> Is there any reason not to?
> 
> -Thue

*looks at profiling* .25 percent of the load is in the relevant functions;
probably more in CVS with FoW. Over 12 percent in functions like
ai_manage_explorer.
The reason it isn't higher in other ai functions is probably that the ai
cheats a little with what it knows..

Anyway, I think the code is cleaner with my patch applied :)

-Thue.