Complete.Org: Mailing Lists: Archives: freeciv-dev: June 2000:
[Freeciv-Dev] Re: goto algoritms
Home

[Freeciv-Dev] Re: goto algoritms

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: goto algoritms
From: Thue Janus Kristensen <thue@xxxxxxx>
Date: Tue, 6 Jun 2000 20:48:32 +0200

> I haven't tried profiling yet, but it would surprice me a lot if
> goto_1.diff was slower than the one currently in CVS. How fast goto_2 is
> in a real game I do not know, but it should depend on the amount of rail.
> Unless goto_2 is substatially slower than goto_1 I suggest we use goto_2,
> as it is always correct, and simpler. Also, as shown the profiling made of
> 1.10, the goto is important, but not that critical to performance.
> 
> -Thue

I tried profiling goto_2 against the one in CVS by running a savegame a
number of years on both.
On a run from -4000 to 0 goto_2 was just under x3 faster.
On a run a bit later in a game on a larger map goto_2 was just over x3
faster.
On a game with mostly ground units and some railroad goto_2 was x2 faster.

When there is more railroad on larger continents I expect goto_2 to
become slower, but I didn't have a savegame handy to test that.
remember that goto_2 also have the advantage over the one in CVS of
always finding the best path.
And remember that the goto I am talking about does not include
generation of the warmap and is not the most performance critical part of
freeciv (only 5-6%).

I haven't tried profiling goto_1, but I espect it to be always faster
than CVS, and slower than goto_2 unless there is alot of RR. However,
like the one in CVS it does not always find the shortest path (which
is why I didn't test it, I really prefer goto_2)...

-Thue



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