Complete.Org: Mailing Lists: Archives: freeciv-dev: September 1999:
[Freeciv-Dev] Re: code optimization ideas
Home

[Freeciv-Dev] Re: code optimization ideas

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Freeciv Development <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: code optimization ideas
From: Peter Schaefer <schaefer@xxxxxx>
Date: Thu, 23 Sep 1999 14:10:55 +0200

Tony Stuckey wrote:
> 
> On Wed, Sep 22, 1999 at 10:02:26PM +0200, Peter Schaefer wrote:
> > About the intention of the patch ..
> > I noticed there is a get_map_tile / adjust(x)*ymax+y cache ..
> > Does it really help ? I'm more in favor of caching the information in the 
> > functions
> > that call get_map_tile, or even caching the value of adjust(x)*ymax+y in 
> > the unit itself -
> > having both the tile cache in get_map_tile and in the unit is no good idea 
> > IMHO .
> >
> > I'm also not sure caching everything everywhere is a good idea ?!
> > Like the tile in the unit, and the x y in the tile .. .
> >
> > Also do not most of the calls to get_map_tile come from pathfinding ?
> > How about putting the terrain into an array all by itself,
> > and putting the stuff not needed by pathfind elsewhere ?
> > This would increase cache hits by only accesing the memory needed by the 
> > pathfind .. maybe .. .
> 
>         One problem is that a lot of the code is just stupid.
>         It will go to 13,27 and look at all 8 surrounding tiles.  Then it
> will go to 13,28 and look at all 8 surrounding tiles, many of which were
> just looked at.  Sometimes this happens multiple times.  This definitely
> happens in the pathfinding stuff, where calls to "is_enemy_unit_tile" and
> similar stuff *have* to be done to check ZOC issues when trying to move
> around.
> 
>         It's not clear to me that caching this data provides a real win,
> though, without making the code massively more convoluted.  Some of it is
> already convoluted enough to be scary.
> 

You could cache it imcompletely, maybe just a flag for every tile that tells 
whether a unit or city is adjacent to it.
If not, there never can be a ZOC into the tile.

I'd like to note that the language used in the code suggests the notion that 
a ZOC is something that allows you to move into a tile; This is not so;
a ZOC is something the enemy has that forbids you to move from one ZOC to
another ZOC. This means you don't have to look at the eight surrounding tiles,
if you have reliably cached ZOC information for this tile, just at the tile you 
are
at and then if an enemy ZOC is on the next tile.
x[ This is just elaborating what Tony meant, I guess.]

I can not tell whether this will make the code hopelessly convoluted;
If all movement and placement of units/cites is threaded through a place_unit
or remove_unit function, it should work, shouldn't it :-)

-- 
Peter Schäfer - mailto:schaefer@xxxxxx, schaefer@xxxxxx

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