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

["Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu>]

> > No, that isn't it.  I can pipe the stuff into |cat >/dev/null instead
> > of Emacs, and it will be finished in a whiffy.  Emacs must be using
> > some sort of system call that _stops_ dd most of the time from being
> > able to so another write to the pipe until the Linux scheduler has run
> > again (which it does at the rate of about 100 per second, almost
> > exactly the rate at which characters arrive).
> That is because emacs is using a pty by default for process i/o (I

But David pointed out several times that asking Emacs to use a pipe didn't
make any difference.

BTW, on my machine (266Mhz PII) the result of his test is basically always
1024.  If I put the process' output in a hidden buffer, I then get mostly
1024 but a few smaller entries, the smaller being 382 on the test run I did.
Looks like my Emacs is just not fast enough.

> Come on yourself...  This illustrates that if you use
>         "tex ... | dd bs=1k"
> instead of just
>         "tex ..."
> in acutex, you'll probably end up with much faster performance
> since you will get buffered output from tex.

But there's still something very fishy: he gets poor performance
while at the same time Emacs only reads one char at a time.
In your interpretation, the reason why only 1 char is read each time
is because Emacs is so fast that it keeps up with the input data, but
then why would the whole thing be so slow (considering that `dd' is
pretty fast when writing somewhere else, even with 1-byte-at-a-time
buffering).
So is it that Emacs ends up somehow slowing down `dd' to a crawl ?  How ?

>         M-: (setq process-connection-type nil)
> before you run your acutex process, and see if that makes a difference.

I think it's pretty clear that his test case is showing anomalous
behavior, based on his description.  And his test case doesn't
use AUCTeX.  I can't reproduce it, tho.


	Stefan