In the earlier sections we saw that the data layouts are implemented as dynamic plugins which are loaded at run time. This gives us the flexibility to run the user applications on different data layouts - even new data layouts about which the user application has no prior knowledge. Since this needs run time function redirection, we use the late binding (virtual functions) mechanism provided by C++. This gives a very fast implementation of data access while maintaining the flexibility we desire.
In certain cases however, virtual function calls might not be fast enough. It is well known that virtual function calls are slightly slower than direct function calls due to pointer dereferencing. Direct function calls however are generated by the compiler at compile-time only. To provide data access using direct calls, the prior knowledge of the data layout would be needed. We have designed the data access mechanism such that the prior knowledge of data layout will give the user application the maximum speed via direct function calls, thus avoiding virtual calls. In Figure 8 we show the options the user has to access data. If the speed of virtual function calls is enough, the user can use the VirtualCall iterator to access the volume data. This iterator automatically calls the correct iterator functions at run time using a virtual function call. In case direct function calls are desired, the user can call the appropriate iterator directly as shown by the solid arrows.
There is also a third option which can combine the two previous options. The user can use a macro defined in OpenVL to call the appropriate iterator directly, or in case the iterator is unavailable, the macro will call the VirtualCall iterator. This type of data access will be fast for data layouts which provide iterator implementations at run time and slow for other layouts which do not. However, this has the drawback of adding some code bloat to the user application because every routine will be implemented for each supported layout type and data type. We suggest that this method be used only where there is a significant performance hit when compared to using the VirtualCall iterator.