Re: Any idea about what makes Emacs slow reading on pipes?

[David Kastrup]

address@hidden (Kai Großjohann) writes:

> Another thought that I'm having is that I wonder whether your kernel
> includes the scheduler changes that are supposed to favor
> interactive applications.  It seems that the kernel might think that
> Emacs is an interactive application, and so it schedules Emacs
> quickly, hoping to improve interactive performance.
> 
> Just a wild stab in the dark.

It pretty obviously does.  Here is a test: start an xterm.  Then run

od -v /dev/zero|dd obs=1

in it.  Then, in some other shell window, type

while true;do :; done

The original xterm grinds to a halt immediately while the shell is
using up its interactivity bonus.  Then the xterm resumes work again,
at a much _higher_ speed than before.  The moment you kill off the
busy loop, the xterm drops to a crawl again.

I remember this "slow start" xterm effect where an xterm got much
faster real time performance on a busy rather than on an idle system
and performance got good only when the xterm could not keep up, from
a lot of single CPU Unices.  One of those quirks one does not think
about much.

And the faster an operating system can switch contexts, and the more
it prouds itself of little latency, the worse the effects get.

Yes, I hope to persuade the Linux kernel crowd of a scheduling policy
that will fix this situation.  But since Emacs runs on a wagonload of
different systems, and this situation is all too common, it would not
do harm to think of a scheme where Emacs does not spend so much time
on every context switch it is handed out generously.

That is, I would like a scheme where Emacs throttles the filter
routine calls for the benefit of other tasks it is not even
responsible for.  It could maintain its own buffer that it fills
on wakeup without further processing until it is either full or until
a certain time since the last processing has elapsed, and only then
do the much more expensive operation of running a filter routine
instead of yielding again to the operating system.

That is, if the operating system is lavish with incurring context
switches on a single CPU system, it may be because it can switch
contexts quite fast.  So we should let Emacs deal with the context
switch fast, too.  Throttling multibyte conversions and filter
routines with the help of a separate buffer should be a way to
achieve that without impacting performance on systems with a smarter
scheduler.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum