Re: MacOS X: Carbon Emacs problem

[Martin Fredriksson <m@rfc.se>]

Thanks for a very informative (and quick!) answer.  The 'dd obs=8k' 
really improved speed!  Great!  The filter did not noticably improve 
speed; I have not experimented with different sleep times (do you want 
me to do that?).

I understand your explanations, but I know much too little about the 
issues to have a clear opinion about what fix is right.

Thanks again!

Martin F

On 1 dec 2003, at 02.16, David Kastrup wrote:

> Martin Fredriksson <martin@rfc.se> writes:
>
>> On 6 nov 2003, at 22.06, Rolf Marvin Bøe Lindgren wrote:
>>
>>> If I call LaTeX from GNU Emacs under Carbon (i.e. the usual way),
>>> then processing takes ages.  if I run Emacs without Carbon,
>>> i.e. emacs -nw, then LaTeX processing runs at the same speed as
>>> when called from the shell.
>>>
>>> latest cvs build of GNU Emacs (this has been this way for a long
>>> time now), latest version of auc-tex.
>>
>> I experience the same.  I think the reason may be that it takes
>> longer to log the result in the latex output buffer on Emacs/Carbon?
>
> Let me guess.  You are working on a single processor system.  The
> reason for this may well be something which I already brought up here
> once which will on _many_ single processor operating systems result
> in _very_ inefficient operation: when Emacs is listening on a pipe,
> it will wake up and process a single byte willingly.  But while Emacs
> is processing this single byte (and Emacs usually is rated an
> interactive application by the scheduler and thus does not get
> preempted), the application producing the byte does not get any CPU
> time.  So when Emacs has finished processing that single byte and
> gives back the CPU to the scheduler, the output generating program
> will again just generate a single byte (or sometimes line) before
> Emacs gets control of the CPU again.  But it is maximally inefficient
> to have a pipe only be processed with such small units.
>
> Try some of the following remedies:
>
> M-x customize-variable TeX-command-list RET
>
> And then append to the TeXing command you usually use
>
> |dd obs=8k
>
> which should fill the pipe with much larger chunks.  Another
> possibility is to do
>
> (defadvice TeX-command-filter (before TeX-pipe-fill)
>   (when (< (length string) 80)
>      (sleep-for 0.05)))
>
> This will, in case the filter function receives only a short string,
> actively yield the CPU for a moment in which the pipe can fill some
> more.  Please report whether this increases throughput on your
> machine.
>
> I am still of the opinion that this problem is so common among
> operating systems (I have the same problem on Linux) that we should
> teach Emacs to voluntary yield a bit of CPU when it finds itself
> processing almost empty pipes all the time.
>
> In general, the current behavior makes almost all comint modes awfully
> slow.  I think one should try to read a full pipe's worth of data with
> small timeout usually.  If the pipe does not get full, then we will
> have had the CPU idle a bit unnecessarily, but that means that the
> output generating application actually leaves us enough time so that
> we can afford it.  The disadvantage is that if we are talking some
> protocol with an interactive daemon process, we will always take at
> least a tick of time to respond.  But maybe one can set a flag when
> sending to some process that will take this sort of CPU throttling off
> the process for the next received data.
>
> -- 
> David Kastrup, Kriemhildstr. 15, 44793 Bochum

--
Martin Fredriksson <m@rfc.se>, phone: +46 730 59 77 00
Guide Konsult Göteborg AB, Sweden