<div dir="ltr">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? </div><span>
</span><p dir="ltr">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. :-)</p><span>
</span><p dir="ltr">I think we can simplify your compiler macro to just two branches using CONSTANTP + EVAL as other such macros do in CFFI. </p><span>
</span><p dir="ltr">Cheers, <br>
Luís </p><span>
</span><br><div class="gmail_quote"><div dir="ltr">On Thu, Aug 17, 2017, 09:07 james anderson <<a href="mailto:james@dydra.com" target="_blank">james@dydra.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">while profiling code which depends on foreign sizes, i observed that foreign-type-size was doing most of the work.<br>
this (so it seems) due to the circularity check.<br>
<br>
is there some reason that there is no logic to decide to push the process into compile-time where it is possible?<br>
<br>
something like:<br>
<br>
(define-compiler-macro foreign-type-size (&whole form type)<br>
(cond ((or (keywordp type) (typep type '(cons (eql :struct))))<br>
         (foreign-type-size type))<br>
        ((and (symbolp type) (constantp type))<br>
         (foreign-type-size (symbol-value type)))<br>
        (t<br>
       form)))<br>
<br>
<br>
<br>
<br>
</blockquote></div>