timing macro expansion

Bug #1156764 reported by il71
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
SBCL
Won't Fix
Undecided
Unassigned

Bug Description

sbcl 1.1.5 x86_64 Linux

Normally the test passes for few seconds with the default 1Gb heap size.
If I put `time' around macro-call, the heap is exhausted. Increasing to 4Gb did not help.
The test is rather artificial as I tried to reduce original one and get reproducible testcase.

$ cat time-macro.lisp

(defparameter arr (make-array '(10 10) :initial-element 1))

(defmacro increment (x y)
  `(incf ,x ,y))

(defun func3 (x list)
  (loop for y in list collect `(increment ,x ,y)))

(defun func2 (list)
  (loop for x in list collect `(progn ,@(func3 x list))))

(defmacro macro2 (&rest l)
  `(progn
     ,@(func2 l)))

(defun func ()
  (let ((res nil))
    (loop for i from 0 below 10 do
      (push `(macro2 ,@(loop for j from 0 below 10 collect `(aref arr ,i ,j)))
            res))
    res))

(defmacro macro ()
  `(progn
     ,@(func)))

(macro)
;(time (macro))
;(print arr)

Revision history for this message
Paul Khuong (pvk) wrote :

That macro expands into 1000 (setf aref) forms. At the REPL, (macro) goes through the trivial interpreter. Wrapping the form in TIME forces it to be compiled, and that doesn't work very well (usually, the issue is with the type propagation pass). Not ideal, but that behaviour isn't likely to change any time soon.

Changed in sbcl:
status: New → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.