Dear [insert something suitable here],

I have complained about the slow speed of Linux Applixware 4.3 screen
updates under NetBSD 1.2.  I have now a new machine (new Asus motherboard,
a real P166) and a new version of XFree (3.3), but the problem remains the
same:

When started, Applixware works fast.  After using it for some time, it
becomes noticeably slow.  I think all internal operations are still
pretty fast, but the screen updates become real slow.  In the beginning,
redrawing the word processor window (a full page of text) takes only
a fraction of a second - after a few hours or working, the same update
may take 10 seconds.  The only known way of "curing" the problem is
quitting and restarting Applixware.  I don't think anything in the
system changes that much (no other users, no other large processes etc).
The machine isn't paging, either (got 64 MB of RAM).

I did a ktrace of one screen update of Applix Words when it's running
slow (one single redraw took 16 seconds on a P166!) and noticed that
Applix makes lots of read(), write(), and oldselect() calls during the
update.  I guess this is how the X protocol works.  Well, the typical
secuence which is repeated _many_ times is this:

1. Applix does a small write()
2. Applix tries to read() and gets E_WOULDBLOCK
3. Applix calls oldselect()
4. After 49...50 ms, oldselect() returns and Applix calls read() again
5. repeat

All the other system calls are fast (usually < 0.5 ms), but the oldselect()
call _always_ takes slightly less than 50 ms.  As this is repeated who
knows how many times during the redraw operation, the delay is multiplied
and becomes 10-15 seconds.

What is going on?  It sounds like if oldselect() was only able to wake up
20 times a second (if I add up the times spent in oldselect() and the other
syscalls, I get _almost_ 50 ms every time the sequence is repeated).

I then restarted Applixware and loaded the same document into Words.
When I ran ktrace of the same page redraw, I saw lots of the same call
sequences - but this time, oldselect() was returning in about 0.7 ms
or less (the worst case seemed to be slightly over 1 ms)!

I can e-mail the kdump output to someone if that helps.  I just hope there
is a solution to this problem because using a word processor which needs
16 seconds to update the window contents after moving focus is a PAIN :-I
If this were on a 286, I could accept it, but on a P166... :-/

Thanks for your attention, folks.

  -jm


-- 

                     ---> http://www.jmp.fi/~jmarin/ <---