Hi Lionel, All my apologizes for such a late (and probably out dated) answer.
> Hello, > > I observed the following memory usage with bmem by launching the executable > a.out compiled with this small piece of code (with bigloo 3.5a to 4.3b): > > a.out 10000 quote > => takes few Kbytes > > a.out 10000 quasiquote > => takes ~ 500 Mbytes (!) > > So my question: is this memory requirement normal for the quasiquote case? > (if yes and if bigloo cannot be fixed, I will replace quasiquotes by quotes > when equivalent like in this case before evaluation) > > Thanks and Best Regards, > Lionel > > > > ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; > > (module a > (main main)) > > ;; eval wrapper to proove all memory is allocated in the my-eval function > with bmem > > (define (my-eval e) > (eval e)) > > (define (main argv) > (when (< (length argv) 3) > (fprint (current-error-port) (format "Usage: ~a <n> quote|quasiquote" > (car argv))) > (exit 1)) > (let* ((n (string->integer (list-ref argv 1))) > (q (string->symbol (list-ref argv 2))) > (e `(,q ,(iota n))) > (r #unspecified)) > (when (< n 10) > (write e) > (newline)) > (set! r (my-eval e)) > (when (< n 10) > (write r) > (newline)) > (print (length r)))) What you are observing here is not the performance of QUASIQUOTE vs QUOTE but the performance of the interpreter. In the first case, when the evaluator evaluates a QUOTE expression, it merely takes the tail of the list passed as argument and that's it. In the second case, it expands QUASIQUOTE into a call to CONS*. In your particular test, it ends up with a very big expression representing the function call with your n arguments. In the compiled code, this would only trouble the register allocation but in the interpreted code, this is another story. The interpreter is optimized for handling as efficiently as it can small number of arguments (currently 4 but increasing that threshold would probably make sense). You are far beyond that value and the interpreter allocates data structure for representing the function call. This could probably be improved by handling CONS* specially but once again, this problem only concerns the interpreter. Compiled codes are not plagued with this problem then I don't think it is a priority to fix it. -- Manuel
