Complete.Org: Mailing Lists: Archives: freeciv-dev: March 2003:
[Freeciv-Dev] Re: Path-finding code is in (PR#2370)
Home

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

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Gregory Berkolaiko <Gregory.Berkolaiko@xxxxxxxxxxxx>
Cc: Freeciv Development List <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: Path-finding code is in (PR#2370)
From: Raimar Falke <rf13@xxxxxxxxxxxxxxxxx>
Date: Thu, 13 Mar 2003 17:46:41 +0100

On Thu, Mar 13, 2003 at 03:54:10PM +0000, Gregory Berkolaiko wrote:
> Bringing discussion back to the list/RT...
> 
> On Thu, 13 Mar 2003, Raimar Falke wrote:
> 
> > On Thu, Mar 13, 2003 at 12:43:34PM +0000, Gregory Berkolaiko wrote:
> > > > > Maybe it's time to change some functions in path_finding into macros 
> > > > > again...
> > > > 
> > > > Please no.
> > > 
> > > Another thing to think about is recycling maps (i.e. not really freeing 
> > > the memory in destroy_map and not allocating new memory in create_map)
> > 
> > I think that the user recycling should be done first. That is that the
> > AI passed struct pf_map * around. This will work for the non-iterate
> > case out of the box. For the iterate case we may have to add a
> > pf_reset function.
> 
> I suspect you are talking about reusing generated maps.  This, of course, 
> should be encouraged.
> 
> I was talking (actually it was Ross' idea) about reusing memory.  Since 
> much time is spent on allocating big chunks, we can have a cache of 
> several maps.
> 
> Right now:
> 1. A call to pf_create_map (a) allocates a map, (b) clears the memory and 
> (c) initializes as appropriate.
> 2. A call to pf_destroy_map frees the memory.
> 
> Proposal:
> 1. A call to pf_create_map will (a) get a currently unused map from the 
> cache, (b) clear the memory and (c) initialize as appropriate.
> 2. A call to pf_destroy_map will mark the map as unused.
> 
> This should be done under the hood, interface should not be changed.

Lets see some numbers:

2: all: gotohand=8,410000s path_finding=22,990000s factor=2,733650
2: mem: gotohand=0,000000s path_finding=0,280000s factor=inf

So the memory management function require only 1% of the total
runtime. Not much to optimize here.

Patch attached.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 Windows: Where do you want to go today?
 Linux: Where do you want to go tomorrow?
 BSD: Are you guys coming or what?

Attachment: time_mem_pf.diff
Description: Text document


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