CSC/ECE 517 Fall 2009/wiki1b 11 cc

Static vs. dynamic o-o languages from the perspective of performance

Typing

---

Object-oriented languages can be analyzed into either dynamical or statical language by their type handling mechanism. The former delays the type decision until run time ( type feedback ), in turn the latter determines and strongly restricts type usage in compile time (concrete type inference ).

One parameter to measure the performance of the code are calls, they not only slow down the program through the calling overhead but also the opportunities to optimize the code are destroyed because of dynamically-dispatched calls. Object oriented programs tendency is to contain more calls at the source level rather than at procedural level since the programming style in object oriented encourages factoring code into small pieces to obtain fine-grained reuse, this pactice makes more difficult the optimization and thus the performance.

It is important to mention that traditional compilers are unable to remove dynamical calls, therefore the object oriented programs usually exhibit a higher calling frequency than procedural programs. The frequent calls, combined with the scarce opportunities for traditional code optimizations, can lead to poor run-time performance.

To eliminate dynamical calls by statically binding or in-lining them, however it is not that easy, even for the statically-typed lenguages

Consider the following C++ code fragment:

GraphicalObject* obj; ... obj->moveTo(0, 0);

Despite the type declaration, a C++ compiler cannot statically bind the “moveTo” call because it does not know the object’s exact class and thus it cannot determine whether “Point::moveTo” or “Rectangle::moveTo” will be invoked

A benchmarking in performance was made in [Set reference], to evaluate the relative performance of dynamic and static the programs were divided into three groups, and then it was executed a suite of 23 benchmarks, Table XX shows them

Static Object-Oriented Language ( type inference )

---

Statically-typed languages require that all variables are declared with a specific type. The compiler will then ensure that at any given time the variable contains only an object compatible with that type. By enforcing the type constraint on objects contained or referred to by the variable, the compiler can ensure calling method error can never occur at run-time. It enforces safer, more reliable code, and increases efficiency of the resulting product as well. On the other hand, a static type system can hinder evolution of software in some circumstances. Upper classes restrict the inherited ones evolving into various form from its strict type-binding. Eiffel , Java , C# , C++ , Visual Basic

Dynamic Object-Oriented Language ( type feedback )

---

A dynamic type system doesn't require variables to be declared as a specific type. Any variable can contain any value or object. In many cases this can make the software more flexible and amenable to change. However, care must be taken that variables hold the expected kind of object. Typically, if a variable contains an object of a different type than a user of the object expects, some sort of calling method error is raised at run-time. On the other hand , if the type of the object is not what it was originally expected to be, it may not understand the messages being sent to it. Even worse that it may be interpreted in a wrong way. Smalltalk , Ruby , Python , Perl

Performance Comparison

---

Table. Performance comparison of type inference and type feedback.

CounterAct

---

Dynamic O-O languages monitors previous executions of the program to determine the set possible receiver classes. In turn , Static O-O languages computes the set of possible receiver classes by analyzing the program’s source code. This characteristics bring consideration opposed to the belief that the static O-O languages are efficient in performance. Compilers cannot predict the typical usage. With this reason, statical way shows more overhead when leading to calling methods called infrequently in case that the methods are small subset of vast method pool.

References

---

External Links

---