Can't think of a particular explanation off the top of my head. I suspect we simply didn't expect performance-critical code to need foreign-type-size. What's your use case?

Alternatively, we could slap some caching on PARSE-TYPE but I'm pretty sure that'll lead to a least one cache invalidation bug down the road. :-)

I think we can simplify your compiler macro to just two branches using CONSTANTP + EVAL as other such macros do in CFFI.

Cheers,
Luís


On Thu, Aug 17, 2017, 09:07 james anderson <james@dydra.com> wrote:
while profiling code which depends on foreign sizes, i observed that foreign-type-size was doing most of the work.
this (so it seems) due to the circularity check.

is there some reason that there is no logic to decide to push the process into compile-time where it is possible?

something like:

(define-compiler-macro foreign-type-size (&whole form type)
(cond ((or (keywordp type) (typep type '(cons (eql :struct))))
         (foreign-type-size type))
        ((and (symbolp type) (constantp type))
         (foreign-type-size (symbol-value type)))
        (t
       form)))