When an application operation is running entirely within the ABL context or entirely within the .NET CLR context, performance is generally the same, respectively, as running the same operation in a pure ABL application or in a pure .NET application. However, any operation that exchanges data between the ABL context and the .NET CLR context (such as a property assignment) incurs some performance penalty over a similar operation running entirely within the ABL or .NET CLR context alone. This is because all such data exchanges involve the movement and conversion of data between one or more corresponding ABL and .NET data types.
Note that a typical GUI for .NET application requires many such data exchanges. However an exchange involving a simple primitive data type, such as an ABL INTEGER or DECIMAL, often incurs an insignificant penalty relative to the native I/O and other processes that drive either the .NET or ABL components of the application. Somewhat larger penalties result from exchanges of larger and more complex data types, such as large ABL LONGCHAR values and especially large arrays, temp-tables, and ProDataSets.
A key to minimizing performance penalties in a GUI for .NET application is to reduce the number and size of data exchanges between the ABL and .NET CLR contexts. In general, GUI for .NET applications perform best when you focus all high-volume data processing within one context and move only the final results to the other context—typically, for display in the .NET CLR context and for storage in the ABL context.
Finally, .NET provides certain class-based data structures (such as hash tables and multi-dimensional arrays) that are not natively supported in ABL but that might seem convenient to hold appropriate data originating in ABL. However, before using such .NET data structures for ABL data, consider the possible performance impact of exchanging that data between ABL and the potential .NET data structure, especially if the typical number of ABL data items or data exchanges is relatively large.
