Subject: Slow X applications [was Re: X server as a Unix system process]
To: Jukka Marin <email@example.com>
From: Chris Dearman <firstname.lastname@example.org>
Date: 07/28/1997 13:08:03
Jukka Marin (email@example.com) writes:
> This brings my Applixware problem into my mind again. Using ktrace, I
> found out that Applixware (the linux version on i386) is doing lots of
> small reads and writes to the X socket. After a write, it calls
> oldselect() which takes 50 ms to return. A word processor screen update
> consists of a thousand (well, it sure looks like that) write/oldselect/read
> chunks of code, most of which take 50 ms.. so the screen update takes 15
> seconds or more. This only happens after Applixware has been running for
> a while. Any new ideas, anyone? :)
FWIW, we've seen the same behaviour with a completely different setup
(a CAD application running on a Sparc system using SunOS 4.1.x).
After a while, the application starts to send single requests instead
of batching them up. This phenomenon only became apparent when we
started using the application over an ISDN link, where the bridging
delays made the behaviour obvious.
Later, Jukka reported that running his application with an X server
that does not use mmap/munmap, made things go much faster. I suspect
that the application is still doing small writes, but the round-trip
time between the application and the X-server is now low enough
that the small packet size is masked.
I realise that this is probably an X related issue now, but if anyone
else has seen this behaviour or has an idea on what may be causing the
sudden switch to small packet sizes, I'd appreciate your views.
Chris Dearman, Algorithmics Ltd, 3 Drayton Park, London, N5 1NU, England
Phone: +44 171 700 3301 FAX: +44 171 700 3400 Email: firstname.lastname@example.org