[slime-devel] C-c C-c of a function referencing a large constant takes a long time to compile
Hello slime-devel, This evening I discovered a nasty annoyance with Slime and OpenMCL when doing C-c C-c to compile a function. The function makes reference to a 46x46x46x46 constant array of integers (defined with DEFCONSTANT). Any such function that refers to the array takes over a minute to compile with C-c C-c. If I have openmcl running in a terminal, the same function will recompile instantly. Here are a few bits of relevant code and *slime-events*: (DEFCONSTANT +LETTER-FREQUENCY-HYPERCUBE+ #4A((((6384784 ... (defun start-decoder (cipher-text pos) (let (m1 (pf 0)) (dotimes (a +modulo+) (dotimes (b +modulo+) (dotimes (c +modulo+) (dotimes (d +modulo+) (let ((sp (aref +letter-frequency-hypercube+ a b c d))) (when (< 0 sp) (let* ((w (modadd a (aref cipher-text pos))) (x (modadd b (aref cipher-text (+ 1 pos)))) (y (modadd c (aref cipher-text (+ 2 pos)))) (z (modadd d (aref cipher-text (+ 3 pos)))) (pfp (* sp (aref +letter-frequency-hypercube+ w x y z)))) (when (< pf pfp) (setf m1 (list a b c d) pf pfp))))))))) m1)) (:emacs-rex (swank:compile-string-for-emacs "(defun start-decoder (cipher-text pos)\n (let (m1 (pf 0))\n (dotimes (a +modulo+)\n (dotimes (b +modulo+)\n (dotimes (c +modulo+)\n (dotimes (d +modulo+)\n (let ((sp (aref +letter-frequency-hypercube+ a b c d)))\n (when (< 0 sp)\n (let* ((w (modadd a (aref cipher-text pos)))\n (x (modadd b (aref cipher-text (+ 1 pos))))\n (y (modadd c (aref cipher-text (+ 2 pos))))\n (z (modadd d (aref cipher-text (+ 3 pos))))\n (pfp (* sp (aref +letter-frequency-hypercube+ w x y z))))\n (when (< pf pfp)\n (setf m1 (list a b c d)\n pf pfp)))))))))\n m1))\n" "two-time-pad.lisp" 5674 "/Users/david/usr/src/ITA Software Puzzles/Two-Time Pad/") nil t 540) (:return (:ok ("T" "65.65")) 540) I'm running SLIME 2005-06-21, OpenMCL 0.14.3-050610a, and Carbon Emacs from CVS on 2005-06-12, OS X 10.3.9, GCC 3.3 from Xcode 1.5.
On Jun 25, 2005, at 1:52 AM, David Steuber wrote:
Hello slime-devel,
This evening I discovered a nasty annoyance with Slime and OpenMCL when doing C-c C-c to compile a function. The function makes reference to a 46x46x46x46 constant array of integers (defined with DEFCONSTANT). Any such function that refers to the array takes over a minute to compile with C-c C-c. If I have openmcl running in a terminal, the same function will recompile instantly. Here are a few bits of relevant code and *slime-events*:
Hi David, You say "If I have openmcl running in a terminal, the same function will recompile instantly." - what does "recompile" mean? Are you sure that you're calling COMPILE on it? I remember mentions of bad performance when compiling constants on openmcl-devel - this could be my memory playing tricks on me, though. -- Brian Mastenbrook brian@mastenbrook.net http://www.iscblog.info/
On Jun 25, 2005, at 10:25 AM, Brian Mastenbrook wrote:
Hi David,
You say "If I have openmcl running in a terminal, the same function will recompile instantly." - what does "recompile" mean? Are you sure that you're calling COMPILE on it? I remember mentions of bad performance when compiling constants on openmcl-devel - this could be my memory playing tricks on me, though.
I was actually copy-pasting the function from Emacs to OpenMCL running in the terminal. Just to be sure, I did COMPILE: ? (compile 'decode-next-letter) DECODE-NEXT-LETTER NIL NIL OpenMCL is a compiler only implementation AFAIK, so function definitions are all compiled anyway. SLIME or Swank (perhaps the swank-openmcl backend) are definitely doing something to make this take a long time. I just have no idea how to figure out what. If +letter-frequency-hypercube+ is being expanded into a temp file, that would certainly be very suspect. If it's just the symbol, then I'm barking in the wrong direction. The dfsl file that holds the definition to +letter-frequency-hypercube+ is about 12MB.
I've got a followup. If I copy the function from my lisp buffer and paste it into the slime-repl buffer, the function evaluates instantly there. So it is only when doing C-c C-c from inside the lisp buffer that I suffer this long delay.
participants (2)
-
Brian Mastenbrook -
David Steuber