Complete.Org: Mailing Lists: Archives: freeciv-dev: January 2005:
[Freeciv-Dev] (PR#11562) Freeciv Server Performance
Home

[Freeciv-Dev] (PR#11562) Freeciv Server Performance

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: kaufman@xxxxxxxxxxxxxxxxxxxxxx
Subject: [Freeciv-Dev] (PR#11562) Freeciv Server Performance
From: "Benoit Hudson" <bh@xxxxxxxxxxxxxxxxxxx>
Date: Mon, 17 Jan 2005 14:48:27 -0800
Reply-to: bugs@xxxxxxxxxxx

<URL: http://bugs.freeciv.org/Ticket/Display.html?id=11562 >

> [jdorje - Wed Jan 12 17:38:42 2005]:
> > The client can run the CM immediately upon getting the update
> > about the new tile status, if it so desires.  Never call the CM for the 
> > client, except when the player acquires a new city.
> > 
> > For AI players, put the city on a list of cities on which to call 
> > auto_arrange_workers at the end of the turn.
> 
> This is possible.  It's a design I've considered before (with a
> pcity->needs_arrange value) but never done any work on.  This could work
> for human players too if CM is done server-side.

There is pcity->server.needs_arrange, so maybe we just need to add
a loop in end_phase (or, maybe, move it all to ai_end_phase).

The reason to do it client-side for humans is (a) client-side to avoid loading
pubserver, at the cost of lack of concurrency; (b) humans will want to see the
correctly optimized city values on the map soon.

> One problem though is this will still rearrange all workers even when
> just one should be placed.

I disagree with "should" here.  For CPU reasons, we want to avoid rearranging
too much; but that's the only reason I can really think of.  If we can rearrange
all workers at acceptable CPU cost, then we should.



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