emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Fix for slow process output processing (please test).


From: David Kastrup
Subject: Re: Fix for slow process output processing (please test).
Date: 05 Jan 2004 16:57:14 +0100
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50

address@hidden (Kim F. Storm) writes:

> Eric Hanchrow <address@hidden> writes:
> > 
> > I've noticed that shell-mode on very recent (i.e., since after New
> > Year's) versions of CVS Emacs on Windows is quite slow, and the
> > CPU usage is high, for a second or two after I hit RET
> > (comint-send-input).  I haven't yet investigated, but if this
> > sounds like it might be related to your patch (which I think, but
> > cannot right now confirm, is present on the Emacs in question),
> > let me know if I can give you any more information.
> 
> Does the problem go away if you do
> 
>         M-: (setq process-adaptive-read-buffering nil) RET
> 
> before starting shell-mode ?
> 
> I suppose that process-adaptive-read-buffering isn't really needed
> on Windows,

Since Windows is slow, anyway?

> so we could just turn it off in lisp/term/w32-win.el.

I suppose the problem could be that the Windows equivalent of
"select" that Emacs uses does a busy wait without yielding the CPU.
Perhaps this depends on the size of the time slice.

So perhaps it would be nice for experiments to be able to set
process-adaptive-read-buffering to something more complicated, like a
property list setting some parameters, at least for the purpose of
debugging.  It might help getting relevant feedback from those using
Windows.  Maybe.

On another note, I just recalled that Linux has recently gained
something they called an "anticipative I/O scheduler" which means that
write requests will not cause the process to be scheduled away
immediately, but rather it gets a chance to produce more output (I
don't think that this related to the pipes here, though, but mostly
for disk writes).  I don't know whether or not one should adapt the
buzz phrase "adaptive buffering" to rather use "anticipative" as the
latter is already "established" in a way.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum




reply via email to

[Prev in Thread] Current Thread [Next in Thread]