[Freeciv-Dev] Re: (PR#7293) Performance of Freeciv
[Top] [All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
<URL: http://rt.freeciv.org/Ticket/Display.html?id=7293 >
On Thu, Jan 22, 2004 at 03:18:34AM -0800, Christian Knoke wrote:
>
> <URL: http://rt.freeciv.org/Ticket/Display.html?id=7293 >
>
> On Thu, Jan 22, 2004 at 02:41:25AM -0800, Raimar Falke wrote:
> >
> > > > I would like to eliminate a lot of this resource wastage by defining a
> > > > minimum hardware requirement and a performance guarantee for this.
> > >
> > > > Stronly related to this are the questions:
> > > > - what are currently the slowest systems where freeciv is used and
> > > > - are the speed on these systems acceptable and
> > > > - if not where is freeciv slow?
> > >
> > > The bottleneck is the client. Actually I don't have acceptable response
> > > times for certain actions in GTK 1, on a 200 MHz K6 with fast PCI gfx.
> > > The bottleneck is the CPU.
> >
> > What actions?
>
> Date: Fri, 7 Nov 2003 19:59:40 +0100
> From: Christian Knoke <chrisk@xxxxxxxxx>
> To: Freeciv Developers <freeciv-dev@xxxxxxxxxxx>
> Subject: [Freeciv-Dev] Speed observations
> Message-ID: <20031107185939.GA1789@xxxxxxxxxxx>
>
> >
> > > So I think it's a good guess to use a P3-500 at minimum. But even then
> > > certains (CMA related) actions may be slow (take several seconds). See my
> >
> > Yes CMA is a major calculation and isn't fast. If your computer is too
> > you can't use it. There is not much I (we) can do here except using
> > another algorithm.
>
> Well, I didn't complain, you asked.
>
> BTW, I think its a combination of (too frequent) windows update and CMA.
>
> See also PR#4376.
>
> IMNSHO these are all bugs and not CMA-immanent.
I measured a bit. My scenario is using a savegame and time the
newturn update. CVS HEAD GTK1 was 0.3s and 1.14.0 GTK1 was 0.4s. Since
this wasn't helpful I activated update_map_canvas's log statement.
CVS HEAD:
2: update_map_canvas(pos=(42,18), size=(5,5), write_to_screen=0)
2: update_map_canvas(pos=(62,30), size=(5,5), write_to_screen=0)
2: update_map_canvas(pos=(25,35), size=(5,5), write_to_screen=0)
2: update_map_canvas(pos=(26,44), size=(5,5), write_to_screen=0)
2: update_map_canvas(pos=(20,44), size=(5,5), write_to_screen=0)
2: update_map_canvas(pos=(26,41), size=(5,5), write_to_screen=0)
2: update_map_canvas(pos=(21,42), size=(5,5), write_to_screen=0)
2: update_map_canvas(pos=(26,38), size=(5,5), write_to_screen=0)
2: update_map_canvas(pos=(23,40), size=(5,5), write_to_screen=0)
2: update_map_canvas(pos=(22,34), size=(5,5), write_to_screen=0)
2: update_map_canvas(pos=(21,37), size=(5,5), write_to_screen=0)
2: update_map_canvas(pos=(3,40), size=(5,5), write_to_screen=0)
2: update_map_canvas(pos=(22,21), size=(5,5), write_to_screen=0)
2: update_map_canvas(pos=(19,19), size=(5,5), write_to_screen=0)
2: update_map_canvas(pos=(6,40), size=(5,5), write_to_screen=0)
2: update_map_canvas(pos=(20,23), size=(5,5), write_to_screen=0)
2: update_map_canvas(pos=(16,19), size=(5,5), write_to_screen=0)
2: update_map_canvas(pos=(7,37), size=(5,5), write_to_screen=0)
2: update_map_canvas(pos=(2,38), size=(5,5), write_to_screen=0)
2: update_map_canvas(pos=(17,23), size=(5,5), write_to_screen=0)
2: update_map_canvas(pos=(15,36), size=(5,5), write_to_screen=0)
2: update_map_canvas(pos=(16,32), size=(5,5), write_to_screen=0)
2: update_map_canvas(pos=(2,35), size=(5,5), write_to_screen=0)
2: update_map_canvas(pos=(6,34), size=(5,5), write_to_screen=0)
2: update_map_canvas(pos=(-1,32), size=(5,5), write_to_screen=0)
2: update_map_canvas(pos=(3,32), size=(5,5), write_to_screen=0)
2: update_map_canvas(pos=(3,29), size=(5,5), write_to_screen=0)
2: update_map_canvas(pos=(16,29), size=(5,5), write_to_screen=0)
2: update_map_canvas(pos=(5,23), size=(5,5), write_to_screen=0)
2: update_map_canvas(pos=(14,22), size=(5,5), write_to_screen=0)
2: update_map_canvas(pos=(18,29), size=(5,5), write_to_screen=0)
2: update_map_canvas(pos=(6,26), size=(5,5), write_to_screen=0)
2: update_map_canvas(pos=(12,26), size=(5,5), write_to_screen=0)
2: update_map_canvas(pos=(15,25), size=(5,5), write_to_screen=0)
2: update_map_canvas(pos=(9,26), size=(5,5), write_to_screen=0)
2: update_map_canvas(pos=(11,22), size=(5,5), write_to_screen=0)
2: update_map_canvas(pos=(11,17), size=(17,13), write_to_screen=0)
The (5,5) calls were probably produced by:
packhand.c:handle_city_packet_common()
if ((draw_map_grid || draw_borders) && can_client_change_view()) {
/* We have to make sure we update any workers on the map grid, then
* redraw the city descriptions on top of them. */
update_map_canvas(pcity->x - CITY_MAP_SIZE / 2,
pcity->y - CITY_MAP_SIZE / 2,
CITY_MAP_SIZE, CITY_MAP_SIZE, FALSE);
queue_mapview_update(UPDATE_CITY_DESCRIPTIONS);
} else {
refresh_tile_mapcanvas(pcity->x, pcity->y, FALSE);
}
We can IMHO queue these updates and redraw the canvas only when
needed. In the case above this would mean that all the city-surround
updates can be merged (and so removed) with the final big update.
I do such merging (on a pixel level and not tile level as it should be
done here) in the FS client.
Compare this with the 1.14.0 output:
2: update_map_canvas(pos=(19,23), size=(1,1), write_to_screen=1)
2: update_map_canvas(pos=(23,23), size=(1,1), write_to_screen=1)
2: update_map_canvas(pos=(22,22), size=(1,1), write_to_screen=1)
2: update_map_canvas(pos=(23,22), size=(1,1), write_to_screen=1)
2: update_map_canvas(pos=(24,22), size=(1,1), write_to_screen=1)
2: update_map_canvas(pos=(22,23), size=(1,1), write_to_screen=1)
2: update_map_canvas(pos=(24,23), size=(1,1), write_to_screen=1)
2: update_map_canvas(pos=(22,24), size=(1,1), write_to_screen=1)
2: update_map_canvas(pos=(23,24), size=(1,1), write_to_screen=1)
2: update_map_canvas(pos=(24,24), size=(1,1), write_to_screen=1)
2: update_map_canvas(pos=(23,23), size=(1,1), write_to_screen=1)
2: update_map_canvas(pos=(14,29), size=(1,1), write_to_screen=1)
2: update_map_canvas(pos=(13,28), size=(1,1), write_to_screen=1)
2: update_map_canvas(pos=(14,28), size=(1,1), write_to_screen=1)
2: update_map_canvas(pos=(15,28), size=(1,1), write_to_screen=1)
2: update_map_canvas(pos=(13,29), size=(1,1), write_to_screen=1)
2: update_map_canvas(pos=(15,29), size=(1,1), write_to_screen=1)
2: update_map_canvas(pos=(14,29), size=(1,1), write_to_screen=1)
2: update_map_canvas(pos=(24,23), size=(1,1), write_to_screen=1)
2: update_map_canvas(pos=(21,21), size=(1,1), write_to_screen=1)
2: update_map_canvas(pos=(22,25), size=(1,1), write_to_screen=1)
2: update_map_canvas(pos=(18,21), size=(1,1), write_to_screen=1)
2: update_map_canvas(pos=(19,25), size=(1,1), write_to_screen=1)
2: update_map_canvas(pos=(16,24), size=(1,1), write_to_screen=1)
2: update_map_canvas(pos=(14,28), size=(1,1), write_to_screen=1)
2: update_map_canvas(pos=(11,17), size=(17,13), write_to_screen=1)
2: update_map_canvas(pos=(17,27), size=(1,1), write_to_screen=1)
2: update_map_canvas(pos=(11,28), size=(1,1), write_to_screen=1)
2: update_map_canvas(pos=(13,24), size=(1,1), write_to_screen=1)
2: update_map_canvas(pos=(11,17), size=(17,13), write_to_screen=1)
2: update_map_canvas(pos=(24,23), size=(1,1), write_to_screen=1)
2: update_map_canvas(pos=(21,21), size=(1,1), write_to_screen=1)
2: update_map_canvas(pos=(22,25), size=(1,1), write_to_screen=1)
2: update_map_canvas(pos=(18,21), size=(1,1), write_to_screen=1)
2: update_map_canvas(pos=(19,25), size=(1,1), write_to_screen=1)
2: update_map_canvas(pos=(16,24), size=(1,1), write_to_screen=1)
2: update_map_canvas(pos=(14,28), size=(1,1), write_to_screen=1)
2: update_map_canvas(pos=(17,27), size=(1,1), write_to_screen=1)
2: update_map_canvas(pos=(11,28), size=(1,1), write_to_screen=1)
2: update_map_canvas(pos=(13,24), size=(1,1), write_to_screen=1)
Raimar
--
email: rf13@xxxxxxxxxxxxxxxxx
"The BeOS takes the best features from the major operating systems.
It's got the power and flexibility of Unix, the interface and ease
of use of the MacOS, and Minesweeper from Windows."
- [Freeciv-Dev] Re: (PR#7293) Performance of Freeciv, Christian Knoke, 2004/01/22
- [Freeciv-Dev] Re: (PR#7293) Performance of Freeciv, Raimar Falke, 2004/01/22
- [Freeciv-Dev] Re: (PR#7293) Performance of Freeciv, Christian Knoke, 2004/01/22
- [Freeciv-Dev] Re: (PR#7293) Performance of Freeciv, Per I. Mathisen, 2004/01/22
- [Freeciv-Dev] Re: (PR#7293) Performance of Freeciv, Raimar Falke, 2004/01/22
- [Freeciv-Dev] Re: (PR#7293) Performance of Freeciv,
Raimar Falke <=
- [Freeciv-Dev] (PR#7293) Performance of Freeciv, Jason Short, 2004/01/23
- [Freeciv-Dev] Re: (PR#7293) Performance of Freeciv, Raimar Falke, 2004/01/24
- [Freeciv-Dev] Re: (PR#7293) Performance of Freeciv, Jason Short, 2004/01/24
|
|