[Ecls-list] Structure accessors

[Matthew Mondor]

Hello again,

BTW: Please don't consider this as a request for the next release, it
only discusses non-urgent possible optimizations for the future.

I noticed that when doing structure slot references within the same
block of code, every reference passes through an explicit function call,
for instance:

 V2 = ecl_function_dispatch(cl_env_copy, VV[24]) (1, V1) /* KEY-STATE */ ;

However, if using a LET binding to the vector KEY-STATE, that binding
will cause a single call to ecl_function_dispatch(), and subsequent
accesses though the custom binding is fast.  In this case a stack
variable is created which is assigned to the vector and reused.

I suspect that eventually the compiler also could automatically create
such temporary pointer variables where it detects multiple references
to the same slot.  Alternatively, possibly that a type of inline slot
access could eventually be used, when the slot type is known and allows
such, similarily to how AREF accesses can sometimes be inlined.
A possibility would be to always automatically create such an implicit
binding at the current lexical level (at first accessor use detected),
which would get reused as necessary within its scope.

This however raises a question about if slot accesses should internally
use implicit thread-synchronization.  I personally think that
thread-safe slot/object access should be left to the developper (i.e.
using explicit locks as necessary, and/or via an unstandard feature
similar to Java's "synchronized").  This could eventually allow an
optimization level similar to C for structure accessors (at least for
vector/array-based ones) in the future.

Also, I understand that a structure slot accessor could be a function,
which could possibly be dynamically redefined.  However, I doubt
that it's necessary for the same code block to immediately use the new
accessor (if it was possible to redefine it in parallel) while it's
still running.  This could be done at the package-level safety (with
implicit synchronization), and a non-inlined function prologue could
still access the symbol at least once, so the next call would be able
to use a new accessor if necessary.  It appears that structure
accessors are implementation-dependent, and their getf/setf expansions,
if changed, would need the code block to be recompiled, anyway.

Of course, CLOS is another topic; and I didn't do any CLOS related tests
lately.  This discussion is only about structures.
-- 
Matt