The purpose of the X1 branch is to provide a sandbox for making a major architectural change to the Dataphor server runtime. The goals of the change are to:
- Improve overall performance by reducing runtime overhead
- Reduce the load on the garbage collector by using value types wherever possible in the representation of values in the Dataphor run-time
- Reduce the overall memory footprint of a running Dataphor server
- Improve the longevity and stability of a Dataphor server
- Bring the runtime one step closer to IL compilation
From an implementation standpoint the main thrust of the change is that rather than using the DataVar/DataValue pair that is currently used as the runtime container for values, the new engine will use native CLR values wherever possible.Edit
For scalar types that already have a native CLR representation, this simply means using the native value rather than wrapping it in a Scalar instance. For scalar types that use streaming, this will involve passing around the StreamID rather than the Scalar instance.
For row types, the change should only be an issue at the CLI boundary, where the row will still be responsible for converting from the native representation of the values it contains to the physical representation for communication.
Table types will be essentially unaffected by the change. Pipelined operations will still be accomplished by passing around a Table instance in the same way this is done currently.
List types should be able to be implemented with a CLR list rather than the ListValue class that is currently used.
The other major consideration is device representations, but since this layer is currently only capable of dealing with scalar values, this problem reduces to converting the device representation to the native representation. Since this is already taking place, the only real change here will be to the scalar type map implementations to have them return only the native representation, rather than the full scalar instance.Edit
The change is expected to impact at least 50% of the code base, possibly more. Due to the size of the change, and in order to make it possible to merge the change back in to the mainline once it is complete, committers are asked to refrain from rearranging code files or moving classes from one file to another.Edit
Although the scope is large, the change is relatively straightforward, so we are hoping that the timeframe will be short. Best case scenario is probably around a month, given our current workload.