* MacOS X: Carbon Emacs problem @ 2003-11-06 21:06 Rolf Marvin Bøe Lindgren 2003-12-01 0:39 ` Martin Fredriksson 0 siblings, 1 reply; 5+ messages in thread From: Rolf Marvin Bøe Lindgren @ 2003-11-06 21:06 UTC (permalink / raw) 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. -- Rolf Lindgren http://www.roffe.com/ roffe@tag.uio.no ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: MacOS X: Carbon Emacs problem 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 0 siblings, 1 reply; 5+ messages in thread From: Martin Fredriksson @ 2003-12-01 0:39 UTC (permalink / raw) Cc: emacs-devel 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? /m -- Martin Fredriksson <m@rfc.se>, phone: +46 730 59 77 00 Guide Konsult Göteborg AB, Sweden ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: MacOS X: Carbon Emacs problem 2003-12-01 0:39 ` Martin Fredriksson @ 2003-12-01 1:16 ` David Kastrup 2003-12-01 2:23 ` Martin Fredriksson 0 siblings, 1 reply; 5+ messages in thread From: David Kastrup @ 2003-12-01 1:16 UTC (permalink / raw) Cc: Rolf Marvin Bøe Lindgren, emacs-devel 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: MacOS X: Carbon Emacs problem 2003-12-01 1:16 ` David Kastrup @ 2003-12-01 2:23 ` Martin Fredriksson 2003-12-01 2:35 ` David Kastrup 0 siblings, 1 reply; 5+ messages in thread From: Martin Fredriksson @ 2003-12-01 2:23 UTC (permalink / raw) Cc: Rolf Marvin Bøe Lindgren, emacs-devel 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: MacOS X: Carbon Emacs problem 2003-12-01 2:23 ` Martin Fredriksson @ 2003-12-01 2:35 ` David Kastrup 0 siblings, 0 replies; 5+ messages in thread From: David Kastrup @ 2003-12-01 2:35 UTC (permalink / raw) Cc: Rolf Marvin Bøe Lindgren, emacs-devel [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 ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2003-12-01 2:35 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 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
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.