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 ------------------------------------------------------------------------------ Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ Ecls-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ecls-list
