Re: a return to struct madness?

[email protected] wrote:
> When I do this by hand, things work wonderfully.  By default, UFFI ends
> up sticking a call to alien:addr into the works, which seems to force
> CMUCL/SBCL to allocate the structure on the heap.  Having this structure
> allocated on the stack is absolutely essential to performance of several
> applications of mine.  The upside is that with-foreign-object works just
> great on OpenMCL; no excess consing.

I've not heard that alien:addr changes the allocation, but it wouldn't
surprise me if it did cons. SBCL and CMUCL have the potential to very
inefficient with alien access if you happen to trigger some consing. I
use alien:addr so that UFFI application code would be the same if
using either heap or stack based allocation. As you likely know,
CMUCL/SBCL stack based and heap based objects are different.  I've not
done any benchmarks for stack-based allocation with UFFI across
platforms.

> Also, I noticed that the OpenMCL inconsistency with get-slot-value still
> seems to be in place; I have to use reader conditionals on whether to
> quote the type name.

That shouldn't be. I did accept a patch from the mail list about 4
months ago that broke quoting with OpenMCL, but I since reverted the
patch. Could you send some sample code to me? Something that requires
reader conditionals in application code in unaccetable. The goal of
UFFI is to get rid of those.
 
> I'm happy to hack out my own solution to this stuff, but I was hoping
> someone would have some useful comments that might allow me to do
> something that fixes it for everyone.

I'm not sure what solution may exist for stack-based object allocation
that avoids alien:addr. But, I've not noticed a performance issue
using alien:addr. But, perhaps I just haven't written code that
triggers a performance issue.

But, to avoid alien:addr, means that application code would have to
differ based upon the application using stack or heap based
code. Also, such an incompatibility would be unnecessary with
AllegroCL, Lispworks, and OpenMCL. I'm open to suggestions, though,
that don't break existing code.

Kevin