Messages in this thread | | | Subject | Re: Scheduling problem with 2.4? | From | (David Kastrup) | Date | 17 May 2003 21:36:29 +0200 |
| |
Andrea Arcangeli <andrea@suse.de> writes:
> On Sat, May 17, 2003 at 01:22:23PM +0200, David Kastrup wrote: > > > > I have a problem with Emacs which crawls when used as a shell. If I > > call M-x shell RET and then do something like > > hexdump -v /dev/null|dd count=100k bs=1 > > this certainly can't be it > > andrea@dualathlon:~> hexdump -v /dev/null|dd count=100k bs=1 > 0+0 records in > 0+0 records out
Argl. Substitute /dev/zero in the obvious place. My stupidity.
Here is a test file for generating further stats from within Emacs. You can call it interactively from within Emacs with M-x load-library RET testio.el RET M-x make-test RET
and you can use it from the command line (if you really must) with emacs -batch -q -no-site-file -l testio.el -eval "(progn(make-test t 'kill-emacs)(sit-for 100000))"
[unhandled content-type:application/emacs-lisp]
It will then output the read stuff from the process followed by statistics of block sizes over each second it ran.
The interactive session tends to be somewhat worse, but the command line version is bad enough for a demonstration.
It is obvious that during most of the time, the pipe only receives single characters.
Again, I am pretty sure that Emacs is at fault too, but I don't understand the implications of what scheduling behavior causes the pipes to remain mostly empty, with an occasional full filling. It would be better if Emacs would not be context-switched into the moment something appears in the pipe, but if the writer to the pipe would keep the opportunity to fill'er'up until it is either preempted or needs to wait. If there was some possibility to force this behavior from within Emacs, this would be good to know.
Thanks,
-- David Kastrup, Kriemhildstr. 15, 44793 Bochum
| |