So far efficiency of the implementation has only been shown by giving
measurement results. These results are bound to the hardware from which
they have been obtained. If we want to give the application
implementors the possibility to choose between different components,
e.g. for implementing a concurrent server strategy, we have to have an
abstract way of describing the efficiency of a software
component.
Unlike profiling oriented performance comparison[ABD$^$97] or
criteria developed for parallel computing[CKP$^$93], we focus on
asymptotic behaviour. Indeed, a model based on processor cycles would
allow more detailed comparison, but it is too tightly coupled to
the implementation platform. Furthermore the model should be capable of
for capturing performance characteristics of a wide spectrum of
software, not only of communication components. Thus we allow some
inaccuracy to be able to compare software components independently of
their concrete mappings to operational platforms. The developers of
the Standard Template Library[SL95] use the 
notation[Knu73, pp. 104-112] to
describe the complexity of the algorithms contained in the library
components. As STL is gaining ground in every kind of application domain,
we decided to adopt this metric and apply it to components in
general. When analysing programs, we observe that they can grow in
time and in space. Important contributions to run-time are
the algorithm's complexity and the number of times a service provided
by the operating system is involved[KEG$^$97]. Hence, we split this
complexity property into these two parts. What concerns space, we will
supply the memory consumption for every component. Memory usage,
however, is not only a factor that has to be observed when aiming at
resource efficient operation or deterministic scaling behaviour. It
also affects execution time, as memory bandwidth is
limited[EBBV95]. Numerous works[KP93,KP96,GS96,TL93,PLC95] have pointed out already that
reducing the value of this property is a powerful line of attack for
achieving efficient data transfer.
If data copying is involved, we can deduct that a
component exhibiting 
memory consumption behaviour, i.e. two
data copy operations are involved for each processed element, will
perform less efficiently than a 
component. Sometimes however, the
less efficient case might be the only possible solution to implement
the component. Summing up, the parameters of the proposed
model[GJO00] comprise the following values:
| Parameter | Description |
|---|---|
| Al | Algorithmic complexity given in notation. Reduction of the
term should not be applied extensively, e.g. if the complexity has
a constant upper limit, but the number of steps involved is  ,
then  shall be given. |
| Sy | Overhead of system services involved in the components
operations. This covers issues such as concurrency control, context
switching or IO operations. denotes upper boundary of system service usage.
The property can be omitted if such services are not used. |
| Me | Total memory consumption exhibited by the component needed to
deliver its service. In general the asymptotic representation might
not be sufficient. Similar to the Al parameter, no
simplification of the term shall be performed. |
Asymptotic complexity assessment alone will not be sufficient for efficiency description. We will continue to give performance measurements which serve as a basis for more detailed comparison on specific platforms. We apply the model to describe the performance of different concurrent server architectures in the following section.