[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Don't use => in COND...
Date: Tue, 16 Jul 85 12:14:27 EDT
From: Ashwin Ram <Ram@yale>
. . .
(cond (p => (lambda (x) q)))
(lambda () (lambda (x) q))
(lambda () (lambda () **value-of-cond**)))
Now, cond-=>-aux is an integrable procedure defined in the T source as:
(define-integrable (cond-=>-aux p f a)
(if p ((f) p) (a)))
This means that two (lambda () ...) forms are evaluated (using up time
and cons cells) each time the COND is called, regardless of whether this
branch is taken or not, i.e., regardless of whether p evaluates to non-nil
or not. Each time these two closures are set up and thrown away.
Presumably, TC compiles this inefficiency away,
> (test-compile (lambda () (cond (p => (lambda (x) q)) (else r))))
. . .
;;; Optimized result:
(LAMBDA () (IF P Q R))
does not. Thus it is very inefficient (wrt both time and cells) to
use this construct, especially in interpreted code. (I have statistics
collected from a rudimentary benchmark to back this statement up. The
difference that was observed was unexpectedly high.)
We are developing a large AI system in T, and I find that we now have to
go back and rewrite the kernel of our system so that it doesn't use this
If the problem is in the "kernel" of your system, then why don't you just
compile it. I don't think it is in the charter of STANDARD-COMPILER to
produce breathtakingly efficient code. It does, however, want to do its
job rather quickly.