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 <ja...@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))) > > > > >
