Re: process I/O is creepingly slow

[Kim F. Storm]

David Kastrup <address@hidden> writes:

> address@hidden (Kim F. Storm) writes:
> 
> > Do you think that the recent addition of process-adaptive-read-buffering
> > is a satisfactory fix for the following bug report?
> > 
> > 
> > David Kastrup <address@hidden> writes:
> > 
> > > Try the following:
> > > 
> > > M-x shell RET ls -l /etc | dd obs=1
> > > 
> > > The resulting process output crawls very very slow at first before
> > > getting on-track.  Things like M-x compile, running AUCTeX and a lot
> > > of other things are very negatively affected in their performance by
> > > this process I/O bug.
> > > 
> > > In GNU Emacs 21.3.50.11 (i686-pc-linux-gnu)
> > >  of 2003-03-27 on lola.goethe.zz
> > > configured using `configure '--prefix=/usr/local/emacs-21' '--with-gtk''
> 
> I have just right now checked and compared the times in shell-mode
> with Emacs-21.3, current CVS with process-adaptive-read-buffering,
> XEmacs-21.4.12, xterm and Gnome terminal (similar geometry and font
> size).  In order not to have Emacs at a disadvantage, I called it with
> -unibyte.  The test command was
> 
> time hexdump -n 1000000 -v /dev/zero|dd obs=1
> 
> The times were:
> 
> Emacs-21.3: 2m15
> Emacs-CVS: about 1m40
> Gnome terminal: about 1m30
> xterm: about 30s
> XEmacs: about 30s

I tried to repeat those tests, and I get something like this:

Emacs-CVS: 38 sec
xterm: 25 sec

Now, if I change the buffer size in read_process_output from 1024 to 10240
I get a significant improvement:

Emacs-CVS: 20 sec

I wonder why we only read 1024 bytes at a time?

Can anybody explain why the limit is so low?  

What bad effects would come from increasing the limit to, say, 10240?

If this isn't desireable in general, I could make the adaptive read
buffering gradually increase the buffer size from the normal 1024.


> 
> >From the visual appearance, the effect of
> process-adaptive-read-buffering did not seem to set in: the cursor
> basically appeared to move by character.  

I don't see this, even with 1024 bytes.

>                                           The visual appearance for
> the good contestants (xterm and XEmacs) basically was a slower start
> picking up speed later.
> 
> I have no clue why this would be the case.  Previous tests of adaptive
> read buffering (although with an earlier version) turned out a vast
> speed advantage at least in connection with the preview-latex package.

That is strange indeed!

-- 
Kim F. Storm  http://www.cua.dk