foreign-type-size implementation

[Luís Oliveira]

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 at 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)))
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/cffi-devel/attachments/20170818/916d58bf/attachment.html>