[Freeciv-Dev] Re: Map coordinate cleanups.

[Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>]

On Sun, Aug 19, 2001 at 02:53:27PM -0400, Jason Dorje Short wrote:
> Raimar Falke wrote:
> > 
> > On Sun, Aug 19, 2001 at 01:04:39PM -0400, Ross W. Wetmore wrote:
> > > The total run times for an exactly identical game show an overall
> > > 25% cost (9 min vs 12 min) for functions over macros for a small
> > > set of the common ones. One could probably refine this by playing
> > > with the set to see which were the key ones.
> > >
> > > My thoughts at the moment are that this would be really useful for
> > > client code that seems to have a performance bottleneck in processing
> > > server packets that can cause it to die from buffer exhaustion. A
> > > small speedup in the client might be enough to keep it ahead of the
> > > wave.
> > 
> > The server is faster in sending out packets than the client can
> > display the changes. I would suspect the improvements in the common
> > code base would also benefit the server. The server justs wins this
> > race. Maybe some of the gui (drawing) code needs to be examined.
> 
> I took a look at some of this code after Vasco explained the problem
> before.
> 
> Right now essentially nothing is buffered client-side.  The client reads
> in a whole buffer of information, which it then scans through packet by
> packet.  However, no further reading is done until the whole buffer is
> exhausted.  Thus the buffer isn't "buffering" at all, and making it
> larger wouldn't help.

But this is only a small change:
 in client/clinet.c:input_from_server() after
    while (1) {
 make a select() to see if there can be data read from the socket
 without blocking. If it is possible do so.

However if the server bombards the client with packets this won't
help. What may interesting is to know how much time each child of
handle_packet_input() needs. This should show a way what has to be
optimized.

> The problem and the reason the client is so slow is that it draws
> graphics *slowly*.  This can be controlled by several "local options";
> when I run an all-ai game and want to test out the GUI as well, I
> generally set all options so that things go really fast and then I never
> get disconnected.
> 
> What is needed, IMO, is a real form of client-side buffering.  This will
> be tricky to do, but should not require threading as Vasco had
> previously said.  When the buffer gets too large, the graphics should be
> automatically sped up (somehow... [1]) so that the client can keep
> pace.  Alternately, it could just be possible for the buffer to grow
> indefinitely...and we can just hope that someday the client catches up.
> 
> Any "efficiency" changes that are made will affect the server far more
> than the client, and so will only make this problem worse.


> [1]  I suggest creating another global variable that has its value
> initially set to 0 and increased depending on the size of the pending
> buffer.  Then the GUI code can check this variable as well as the local
> options in deciding what graphics/animations to draw.

This is also an interresting option.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "SIGDANGER - The System is likely to crash soon"