Efficiency in RESOLVE/C++

Index:

Abstract
Calendar
Project Development
Findings and Contributions
Links and References
Return to Europa

Abstract:

RESOLVE/C++, the language used in the Software Component Engineering course sequence, has been found to be inefficient. This loss of efficiency is clearly evident in programs that involve heavy mathematical computations and is in the broad sence attributed to the generality inherent in all components written in RESOLVE/C++. This project involves performing various tests on this language to find out what factors lead to the loss of time, and which of them is results in a significant loss. Finally, if possible to find out ways by which the loss can be minimized.

Calendar:

• Project Started:
  June 27, 2002



• Project Completed:
  August 20, 2002

Project Development:

There have been various speculations as to what causes the loss of efficiency in RESOLVE/C++. Many users of this language including me believe that the loss is the result of the idea of reusability that is inherent to all RESOLVE/C++ components. To make all components reusable the components are designed to be as general as possible and are developed as templates which can then be specialized to serve the purpose in an application. This generality leads to code that is extensively layered and these multiple levels of layering lead to a code that is more complex and and at the same time less efficient. The problem with this idea was how much of the loss could be attributed to layering.

Next came the idea of checking components, which lead to extensive loss of CPU cycles. The problem with this that if non checking components are to be used in an application then the programmer must make sure that the components he is using are not layered on checking components. This becomes pretty ugly for components which are deeply layered. One must also make sure that a non checking foundation is used (which can be done by defining 'NON_CHECKING_FOUNDATION'). However, the problem with this was that while linking the foundation with the application a precompiled foundation is used and so in reallity a non checking foundation is not used.

Finally, the last factor that results is inefficient code is that operations in some componets are implemented recursively. The best example of a recursively implemented component is the tree componet which I used for the implementation in the Sorting in Linear Time project. The use of the tree component resulted in a code that was distinctively slower.

Findings and Contributions:

When using RESOLVE/C++ to make applications the programmer must make sure that after the testing is done all the checking components must be replaced by non checking ones. This includes making sure that the components used are not layered on other checking components.
Furthermore, a non checking foundation must be used, and even though defining 'NON_CHECKING_FOUNDATION' should remove all the checking, it does not happen that way as a precompiled foundation is used during the linking phase. Thus to use a non checking foundation the RESOLVE/C++ foundation must be recompiled.

Links and References:

Sorting in Linear Time

  Return to Europa