Programmers are increasingly programming by component assembly. This is despite the fact that the use of components tend to decrease the performance of the program. The programmers who design the components do not know anything about the environment the components will be used in, and can therefore not tailor the components for each specific use. The efficiency of a program suffers from the use of such generic components, since it fundamentally depends on the interactions between the components. The performance of a component based program is therefore often less than optimal. Optimizing component interaction is a fundamental problem in constructing efficient component-oriented programs.
Many computer programs, which consist of a number of program components, manipulate implementation properties such as string representations and data structure for which any of a number of implementation properties can be used. For example, string representations that can be used include: UNICODE, ASCII, and EBCDIC. As another example, data structures that can be used include: trees, compressed files and hash tables. In fact, in many database and virtual machine benchmarks, substantial amounts of time are lost in converting data representation values back and forth between a number of different representations.
One problem solved by this invention is that of minimizing the number of transformations of implementation property values, such as data structure values, back and forth over the course of a run of a computer program.
For consistency of definition in the context of the present application, it should be understood that the term “property”, with respect to an object or component of a computer program, is broad, and includes narrower terms such as “location”, “parameter”, and “implementation”. In turn, “implementation” includes “data representation” such as “string representation” (e.g. ASCII, EBCDIC, UNICODE) and “data structure” (e.g. hash, tree, compressed). Thus, it will be understood that “implementation” does not encompass “location”, nor “parameter” within its meaning. Moreover, in the context of the present invention, “object”, “entity”, and “component” shall be interpreted as having substantially the same meaning, while “library” shall be understood to mean a group of object definitions or component definitions.
USPTO Backgrounds
USPTO Backgrounds