Complete.Org: Mailing Lists: Archives: freeciv-dev: November 2002:
[Freeciv-Dev] Re: (PR#2370) Path finding
Home

[Freeciv-Dev] Re: (PR#2370) Path finding

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: rf13@xxxxxxxxxxxxxxxxx
Subject: [Freeciv-Dev] Re: (PR#2370) Path finding
From: "Per I. Mathisen via RT" <rt@xxxxxxxxxxxxxx>
Date: Sat, 23 Nov 2002 07:52:45 -0800
Reply-to: rt@xxxxxxxxxxxxxx

On Sat, 23 Nov 2002, Raimar Falke via RT wrote:
> First: inlining. It is critical that this is done. Gregory uses macros
...
> while I use the inline keyword. Both can provide the same results.

That Greg's version does not need to open the inline can of worms is a
good thing. If we do add inline at a later time, his macros can always be
turned into functions at that time.

> Second: the speed depends strongly on the size of the node/cell. It is
> currently about 20 bytes. It is possible to cache certain data but
> this make the node/cell larger. I'm using defines:
>
> #define CACHE_TILE
> #define CACHE_ECOT
> #define CACHE_COP
>
> to control what is cached. However what should be cached depends on
> how expensive the functions are (we can't tell this for ECOT) and how
> this related to the memory system of the computer.

Figure out what is needed, and then remove those we don't use. Don't leave
dead code in there.

> So while currently caching the tile is good it may not if we inline the
> map_get_tile function at some point.

I say we change get tile into a macro now, and check if we need tile
caching afterwards. If we add inlining later, it can be changed from macro
to inlined function then. map_get_tile() is, I believe, one of the
functions we previously agreed we should macroify for performance, but
nobody turned up with a patch for it.

> Third: while not related to size of the node/cell it is similar to the
> second point: use of a 1D array or use of a 2D array. I also have a
> USE_2D define for this and _at my computer_ the 2D array is faster by
> 4%.

4% isn't much and doesn't warrant more complex code, unless there are
other good reasons for it.

> Fourth: how general/special do we want the queue implementation. If we
> for example typedef that the queue works on shorts (16bit, less
> memory) instead of void pointers or int we can get some speed. However
> this makes the queue not general.

And what does this actually mean? What can't we do with the queue if it is
typedefed to shorts instead of pointers?

  - Per




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