Optimizing Code Using UFFI
Prev | Chapter 2. Programming Notes | Next

## Optimizing Code Using UFFI

### Background

Two implementions have different techniques to optimize (open-code) foreign objects. AllegroCL can open-code foreign object access if pointers are integers and the type of object is specified in the access function. Thus, UFFI represents objects in AllegroCL as integers which don't have type information.

CMUCL works best when keeping objects as typed objects. However, it's compiler can open-code object access when the object type is specified in `declare` commands and in `:type` specifiers in `defstruct` and `defclass`.

Lispworks, in converse to AllegroCL and CMUCL does not do any open coding of object access. Lispworks, by default, maintains objects with run-time typing.

### Cross-Implementation Optimization

To fully optimize across platforms, both explicit type information must be passed to dereferencing of pointers and arrays. Though this optimization only helps with AllegroCL, UFFI is designed to require this type information be passed the dereference functions. Second, declarations of type should be made in functions, structures, and classes where foreign objects will be help. This will optimize access for Lispworks

Here is an example that should both methods being used for maximum cross-implementation optimization:

    (uffi:def-type the-struct-type-def the-struct-type)
    (let ((a-foreign-struct (allocate-foreign-object 'the-struct-type)))
      (declare 'the-struct-type-def a-foreign-struct)
      (get-slot-value a-foreign-struct 'the-struct-type 'field-name))

Prev | Up | Next
Foreign Object Representation and Access | Home | Declarations