From: David Kastrup <dak@gnu.org>
Cc: "Rolf Marvin Bøe Lindgren" <r.m.b.lindgren@usit.uio.no>,
emacs-devel@gnu.org
Subject: Re: MacOS X: Carbon Emacs problem
Date: 01 Dec 2003 02:16:14 +0100 [thread overview]
Message-ID: <x5ptf9cp7l.fsf@lola.goethe.zz> (raw)
In-Reply-To: <E4369F92-2396-11D8-B0AD-000A9573DA0A@rfc.se>
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
next prev parent reply other threads:[~2003-12-01 1:16 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-11-06 21:06 MacOS X: Carbon Emacs problem Rolf Marvin Bøe Lindgren
2003-12-01 0:39 ` Martin Fredriksson
2003-12-01 1:16 ` David Kastrup [this message]
2003-12-01 2:23 ` Martin Fredriksson
2003-12-01 2:35 ` David Kastrup
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=x5ptf9cp7l.fsf@lola.goethe.zz \
--to=dak@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=r.m.b.lindgren@usit.uio.no \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.