Hi,
I've added some code to send the output for *slime-output* across a dedicated network stream. This is quite a bit faster, but the main advantage is that Emacs remains more responsive if we get a lot of output from the Lisp. This was particularly problematic with XEmacs. The drawback is that this scheme bypasses the state machine and the added complexity for the second channel. Also, this isn't a true solution but only hides the problem.
The new scheme is currently only available for CMUCL and SBCL. The old scheme can still be used, selectable with *use-dedicated-output-stream*.
Comments?
Helmut.
Helmut Eller e9626484@stud3.tuwien.ac.at writes:
Hi,
I've added some code to send the output for *slime-output* across a dedicated network stream. This is quite a bit faster, but the main advantage is that Emacs remains more responsive if we get a lot of output from the Lisp. This was particularly problematic with XEmacs. The drawback is that this scheme bypasses the state machine and the added complexity for the second channel. Also, this isn't a true solution but only hides the problem.
Where does the speed come from?
Raymond Toy had reported the inefficiency that all output from Lisp ends up getting logged in the *slime-events* buffer, which is fairly expensive because of hideshow-mode + font-lock-mode.
If the main win from the dedicated connection is just to bypass that, it could be simpler to hack `slime-log-event' to ignore output messages (or just drastically abbreviate them).
Possibly the whole event-logging thing should be made optional, though I'm loathe to remove debugging information from the default setup if it can be optimised instead.
-Luke
Luke Gorrie luke@bluetail.com writes:
Where does the speed come from?
Don't know exactly. The event-logging is quite expensive, but things are still slow without logging. Below are some numbers for this program:
(defun output-test1 () (time (loop for i from 0 to 200000 do (progn (print i) (force-output)))))
For an xterm, a single channel variant without logging, with logging, and the new scheme with a second channel. I deleted the repl and events buffers before running the benchmark and the repl window was never visible. Everything in Emacs20.
xterm ; 14.14 seconds of real time ; 1.98 seconds of user run time ; 1.3 seconds of system run time
no logging single channel ; 41.67 seconds of real time ; 7.53 seconds of user run time ; 1.16 seconds of system run time
with logging single channel ; 184.34 seconds of real time ; 7.93 seconds of user run time ; 0.96 seconds of system run time
second channel. ; 6.52 seconds of real time ; 2.74 seconds of user run time ; 0.88 seconds of system run time
Helmut Eller e9626484@stud3.tuwien.ac.at writes:
xterm ; 14.14 seconds of real time ; 1.98 seconds of user run time ; 1.3 seconds of system run time
no logging single channel ; 41.67 seconds of real time ; 7.53 seconds of user run time ; 1.16 seconds of system run time
with logging single channel ; 184.34 seconds of real time ; 7.93 seconds of user run time ; 0.96 seconds of system run time
second channel. ; 6.52 seconds of real time ; 2.74 seconds of user run time ; 0.88 seconds of system run time
Weird! Can it be PRINT1/READ? Surely not.
Anyway, let's keep this separate stream :-)
-
Helmut Eller -
Luke Gorrie