[cffi-devel] optimization opportunities for type translators

[rif]

> Snipped from Joerg-Cyril Hoehle's message:

> IMHO this hurts. It hurts even more so, since CFFI originaly started
> out from disatisfaction with UFFI on cmucl, where James Bielman
> observed boxing of float values IIRC, and he initially reported
> performance improvements over UFFI using his approach.  Right now, I'd
> expect CFFI to lag far behind UFFI in performance (at least with
> typedefs and structs, other tests are still compiled fine).

I actually agree with most of the content of your message, but wanted
to point out that on SBCL, CFFI is orders of magnitude faster at
dealing with structs than UFFI.  Basically, UFFI generates SBCL code
with no type declarations, which means that every access to a
slot-value in a foreign struct generates (I kid you not) 250,000 bytes
of consing as it called naturalize and compiles up some closures.
CFFI, because its struct representation is directly in bits (as I
understand it), avoids the SBCL alien functions for accessing the
structure, and is way way faster.  (It is possible to write efficient
SBCL alien code directly (NOT UFFI), but I have not yet found a way to
do it without declarations that are quite painful).

So I always want things faster, but on SBCL, CFFI is making me VERY
VERY happy compared to UFFI.

Cheers,

rif