On 2017-08-18, at 16:11, Luís Oliveira luismbo@gmail.com wrote:
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?
i am reading things from an lmdb instance and this is an integrity check.
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. :-)
sounds like something which would be waiting to break.
I think we can simplify your compiler macro to just two branches using CONSTANTP + EVAL as other such macros do in CFFI.
i am not sure my tests are correct and am not sure how parnoid they should be. constantp stil needs to distinguish between keyword, defined constants and quoted terms. i did not investigate the respective forms which is delivered to the compiler macro, but i do not think that i got it correct.
best regards, from berlin,
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)))