Complete.Org: Mailing Lists: Archives: freeciv-dev: January 2005:
[Freeciv-Dev] (PR#11828) patch: partial city update for what-if scenario
Home

[Freeciv-Dev] (PR#11828) patch: partial city update for what-if scenario

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: bh@xxxxxxxxxxxxxxxxxxx
Subject: [Freeciv-Dev] (PR#11828) patch: partial city update for what-if scenarios
From: "Jason Short" <jdorje@xxxxxxxxxxxxxxxxxxxxx>
Date: Fri, 7 Jan 2005 20:27:58 -0800
Reply-to: bugs@xxxxxxxxxxx

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

> [bhudson - Fri Jan 07 06:00:20 2005]:
> 
> Here's a patch to do a partial update to the city: if the caller 
> knows the production, then we can update the city in half 
> the time of a generic_city_refresh.
> 
> The patch includes a one-line change to the cm to use the new
> function.  The cm.sav.gz in PR#10203 takes 3.8s in the CM rather
> than 4.8s on load; and the CM on Boston takes ~.3s rather than ~.7s

To me this seems overcomplicated and error-prone for something that just
gives a 50% speedup in generic_city_refresh (even though
generic_city_refresh may be 20% of the server runtime).  I'd rather
spend time trying to get an algorithmic improvement in cm.c (for the
"problem cases" where a query takes 1s), and keep the options available
within city.c pretty small.

One thing that is possible is to use more caching within
generic_city_refresh.  Benoit, you had a patch to do this a while ago,
and I made one as well.  However I think we should consider caching the
tile output values (the return values of base_city_get_tile_output,
called by get_worked_tile_output).  This means a non-cached refresh
would have to calculate tile output for ALL tiles rather than just
worked tiles (not a problem since for small cities we have no speed
issue).  However it would mean for cached refreshes we wouldn't have to
recalculate these values.  Based on late-game profiles (see PR#11562) I
belive these function calls (which require many effects lookups) account
for about 1/3 of the refresh time.

That said, I'm not adamantly opposed to a more complicated solution. 
But I think we should see how much speedup we can get while keeping
things simple first.

-jason




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