[Freeciv-Dev] Re: (PR#2521) general effects framework

["Ben Webb via RT" <rt@xxxxxxxxxxxxxx>]

On Mon, Dec 09, 2002 at 08:24:30AM -0800, Mike Kaufman via RT wrote:
> On Mon, Dec 09, 2002 at 01:00:18AM -0800, Raimar Falke via RT wrote:
> > And last but not least: you add 1k lines of code. And you need another
> > 1-5k to make use of all this. How good does the result perform? How
> > long will effects_update_all take. How much time will an city_update
> > need?
> this is impossible to say until _all_ hardcoded effects are gone in the
> code. This will _not_ be a hindrance to inclusion in the codebase. Please
> look at the patch. A lot of code gets deleted and moved here as well.
> Remember also that gen-impr via Ben's AC patches (just to get the effects
> working) would require just as much or more code. that's just the way it
> is. This is a complex problem.

Indeed. The current impr-gen patch weighs in at 287K, although that does
cover pretty much everything required for improvement/nation/gov/unit
effects. (It's just the AI that is lacking, to date.)

> I was extremely worried about this performance of effects_update_all() and
> I'm still a bit anxious, but for a ruleset without conditional effects, an
> update will only need to iterate over all the effects (in all the lists)
> once. This is not too bad. In the tests I've run, a typical player might
> have 50 or so effects going in the late game.

The similar function in impr-gen makes no noticeable difference to
runtimes in my own general usage. You'd probably notice it in insanely
big games where every player has hundreds of cities though.

> The cacheing could also be made better since several of the cond_* don't
> change often (like cond_nat) we could add some parameters to
> effects_update_all() that takes this into account. The part that makes me
> anxious is the AI. Normally, one wouldn't have to update very often (when
> an improvement is created/destroyed, a tech is discovered, a government is
> changed, a new island is discovered. There may be a couple others. The ai
> is going to have to call it quite often when figuring out what to build,
> research. This is going to have to require some thought, but right now, I
> see no way around it. you?

Oh sure. I have pseudo-code for several such partial updates. It's not
"real" code in impr-gen yet because the patch is already quite big, and
I don't have the time right now. OK, here's an example. Say you build an
Airport. There's no need to do an effect update here, because no other
building depends on the Airport, no other building lists it in its
equiv_dupl or equiv_repl fields, and no other effect lists the Airport
in its cond_bldg field, or its effects in its cond_eff field. In fact,
all you need to do is consider whether to activate the effects of the
Airport itself. (Destruction of an Airport is similarly easy.) Similarly,
many techs are not cond_tech for any effect, or obsolete_by for any
building, so no update is required when they're discovered. etc. etc.
All of this can of course be determined at ruleset loading time, so it's
just a matter of maintaining a list of "safe to skip a full update"
improvements, techs, govs, etc. You can take this further - for example,
some techs do obsolete some buildings, but those buildings themselves
aren't dependencies for other buildings or effects, so you can just
remove the effects of the obsoleted buildings without then having to do
an update (I call this a "semi-safe" tech). Of course, this rapidly
becomes complicated, and so can, IMHO, be left until the patch actually
a) works and b) is included. You know what is said about premature
optimization...

        Ben
-- 
ben@xxxxxxxxxxxxxxxxxxxxxx           http://bellatrix.pcl.ox.ac.uk/~ben/
"People that are really very weird can get into sensitive positions
and have a tremendous impact on history."
        - Vice President Dan Quayle