|Eiffel and Efficiency Issues email@example.com (1990-06-07)|
|Re: Eiffel and Efficiency Issues firstname.lastname@example.org (1990-06-14)|
|Re: Eiffel and Efficiency Issues email@example.com (1990-06-20)|
|Re: Eiffel and Efficiency Issues firstname.lastname@example.org (1990-07-07)|
|From:||email@example.com (Kim Rochat)|
|Summary:||Routine lookup costs|
|Keywords:||eiffel, code, optimize, OOP|
|Organization:||Interactive Software Engineering, Santa Barbara CA|
|Date:||Sat, 07 Jul 90 14:55:43 GMT|
In article <1990Jun20.firstname.lastname@example.org>, email@example.com
(Jim Patterson) writes:
> In article <graham.644716278@bizet> firstname.lastname@example.org (Graham Matthews)
> >In the Eiffel reference manual there are claims that Eiffel code (ie: C code
> >generated by Eiffel) executes 20-25% (I think these figures are right?)
> >slower than native C code.
> I spent a bit of time working with version 2.1c of the Eiffel compiler
> (arouind 1988). The generated code appeared to spend a good deal of
> time doing table lookups in order to implement multiple inheritence.
... omitted description of Eiffel 2.1 routine lookup mechanism ...
The topic of Eiffel routine call costs is a little more complicated
than it first appears.
1) By default, all routines are dynamically bound. This requires a
constant-time lookup for each routine call.
2) When the Eiffel post-processor is used, calls to routines which
do not have to be dynamically bound (that is, they always call the
same routine) have their routine lookup optimized away by the
post-processor and become normal C function calls.
You can think of the post-processor as being the "system builder".
Which routines can have their lookup optimized out is knowable only
in the context of a complete system (set of classes).
3) Some procedures are inlined by the post-processor,
completely eliminating routine call overhead. We plan to
extend inlining to functions and apply it more extensively
in subsequent compiler releases.
4) When routine lookup is required, turning on the C optimizer can
provide dramatic improvements in speed, since the routine lookup
expression is complex enough to provide several opportunities for
5) Running with precondition or assertion checking on greatly slows
routine execution due to additional routine entry overhead, but
this has nothing to do with the inherent costs of routine lookup.
I made some measurements of these cases on a Sparcstation for invocation
time of a function accepting one integer argument and returning it as
the function result. The Sun C compiler was used in all cases. The
alpha version of Eiffel 2.3 was used. Routine invocation times are
normalized and approximate. The cost of a normal C routine call
compiled with optimization on represents one.
Description Normalized time
C, optimized 1
Eiffel, C-optimized, no lookup 1
C, not optimized 3
Eiffel, C-optimized, with lookup 4
Eiffel, not C-optimized, with lookup 10
Eiffel, not C-optimized, with lookup, preconditions on 220
Note that these times are just the for the routine call and return.
These figures should be weighted by the average time required to
execute the routine body to reach any conclusions about relative speeds
of complete programs.
> Frankly, the 20-25% figure seems pretty low to me. It's not really
> so much that the code is of poor quality (though there is some slop),
> but that the computational model is at a higher level and quite a bit
> more complex than C.
Agreed. You can see that there are many variables governing Eiffel
performance, even for a measure as simple as routine invocation costs.
Under the proper conditions, it can meet or beat C. In the worst case,
it is many times slower. ISE is actively working to reduce the costs
incurred when precondition checking is enabled and do more optimization
of lookups and inlining of routines.
Using C compiler optimization is a big winner for Eiffel performance.
Interactive Software Engineering
Responses to: email@example.com
Return to the
Search the comp.compilers archives again.