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 03:35:17 +0100 [thread overview]
Message-ID: <x51xrpclju.fsf@lola.goethe.zz> (raw)
In-Reply-To: <4E2ACA66-23A5-11D8-88C9-000A9573DA0A@rfc.se>
[Toppost rearranged]
Martin Fredriksson <m@rfc.se> writes:
> > 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.
> 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?).
Before you do that, it might make more sense to just activate the
advice in the first place. I am so stupid. Try
(defadvice TeX-command-filter (before TeX-pipe-fill activate)
(when (< (length string) 80)
(sleep-for 0.05)))
[rest snipped to spare the list a repetition of my proposal]
It would also be nice if you tried looking at what difference in real
time those changes make on your machine, just to press home the point.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
prev parent reply other threads:[~2003-12-01 2:35 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
2003-12-01 2:23 ` Martin Fredriksson
2003-12-01 2:35 ` David Kastrup [this message]
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=x51xrpclju.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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).