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)))
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@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)))
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)))
On Fri, Aug 18, 2017 at 4:43 PM, james anderson james@dydra.com wrote:
i am not sure my tests are correct and am not sure how parnoid they should be.
This passes the CFFI test suite:
(define-compiler-macro foreign-type-size (&whole form type) (if (constantp type) (foreign-type-size (eval type)) form))
Does it work for you?
On Fri, Aug 18, 2017 at 4:43 PM, james anderson james@dydra.com wrote:
i am not sure my tests are correct and am not sure how parnoid they should be.
This passes the CFFI test suite:
(define-compiler-macro foreign-type-size (&whole form type) (if (constantp type) (foreign-type-size (eval type)) form))
We could use constantp and eval-constant from https://github.com/sionescu/static-vectors/blob/master/src/constantp.lisp, which cover a few more cases. Do you think it would be worth extracting those to a small separate library ?
On Fri, Aug 25, 2017 at 11:14 AM, Stelian Ionescu sionescu@cddr.org wrote:
We could use constantp and eval-constant from https://github.com/sionescu/static-vectors/blob/master/src/constantp.lisp, which cover a few more cases. Do you think it would be worth extracting those to a small separate library ?
How about Alexandria, UIOP or... CFFI-SYS? Alexandria is probably more geared towards pure Common Lisp. UIOP would probably be a good place, although I don't fully understand how we can ensure Quicklisp loads a recent enough version of UIOP. CFFI-SYS would at least be slightly better since it could be shared between CFFI and static-vectors.
-
james anderson -
Luís Oliveira -
Stelian Ionescu