[Top][All Lists]
[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
- Re: Fix for slow process output processing (please test)., David Kastrup, 2004/01/03
- Re: Fix for slow process output processing (please test)., Eric Hanchrow, 2004/01/03
- Re: Fix for slow process output processing (please test)., Kim F. Storm, 2004/01/04
- Re: Fix for slow process output processing (please test).,
David Kastrup <=
- Re: Fix for slow process output processing (please test)., Eli Zaretskii, 2004/01/05
- Re: Fix for slow process output processing (please test)., David Kastrup, 2004/01/05
- Re: Fix for slow process output processing (please test)., Jason Rumney, 2004/01/05
- Re: Fix for slow process output processing (please test)., Kim F. Storm, 2004/01/05
- Re: Fix for slow process output processing (please test)., Jason Rumney, 2004/01/05
- Re: Fix for slow process output processing (please test)., David Kastrup, 2004/01/05
- Re: Fix for slow process output processing (please test)., Jason Rumney, 2004/01/05
- Re: Fix for slow process output processing (please test)., Kim F. Storm, 2004/01/06
- Re: Fix for slow process output processing (please test)., Kim F. Storm, 2004/01/05
- Re: Fix for slow process output processing (please test)., David Kastrup, 2004/01/05