Detailed explanation of the Enable Short Char feature
|Date:||21 July 2008|
|Product/Release:||LANSA V11 SP5|
|Abstract:||Further explanation on the new SP5 partition level feature Enable Short Char|
|Submitted By:||LANSA Technical Support|
Refer to the LANSA SP5 documentation for details of the partition level option Enable short Char.
This setting indicates whether special Short Char handling should be generated to improve the runtime performance of Visual LANSA applications using the full RDMLX types of String and Char.
By default the Visual LANSA runtime maintains the current value of a String/Char field by dynamically allocating a piece of memory long enough to store the field’s current value. This is an efficient memory management mechanism when the length of a field’s current value is generally much less than the field’s defined length. On the down side, this mechanism does incur a performance overhead in order to manage the allocation and de-allocation of the piece of memory. This overhead can impact the performance of large working lists that include String/Char fields.
In order to minimize this overhead, Visual LANSA has the facility to generate Short Char handling for String/Char fields. Short Char support is implemented by a single allocation of memory that can store the largest value allowed by the field’s length. This feature saves the overhead of per value memory management, but this improved performance comes at the expense of a slightly larger memory allocation.
When the disabled setting is selected, Visual LANSA will treat all fields of type String and Char the same, irrespective of length.
To enable this setting, a level from one to nine is selected. Each level corresponds to a multiple of 32 such that the level multiplied by 32 derives a Short Char length. All Visual LANSA fields of type String or Char whose length is less than or equal to the Short Char length will be implemented as a Short Char.
The most appropriate setting requires a judgment call that balances improved performance against increased memory usage. Furthermore, the longer the String/Char field the greater the probability that much of the piece of memory allocated for the field’s value will never be used. A reasonable balance can be achieved using a level around 2 to 4.
Since this setting changes the way String and Char fields are defined in generated code, this setting can impact the entry length of any working list that contains a String/Char field. Any changes to a working list’s entry length will impact the compatibility of working lists that are passed to RDML functions. Consequently, whenever this setting is changed all Visual LANSA functions and components should be rebuilt.