> On 2017-08-18, at 16:11, Luís Oliveira <luis...@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 <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))) > > > >
