Re: performance of Generic and strings

[Marin David Condic <condicma@bogon.pwfl.com>]

Thomas Rutstr�m wrote:

> Hi
>
> Is there anyone who can tell me exactly what it is that makes generic
> procedures so slow compared to non-generic procedures?
>
> I am also interested in techniques that will speed up the use of strings
> in Ada?

The first question is: What compiler/version and processor/operating-system
are you working with? There should be nothing that makes generic procedures
inherently *substantially* slower than non-generic procedures so it would
help to identify the implementation.

Generally, an implementation would require one more layer of indirection in
references to things which are generic sort of like the extra layer of
indirection implied by object oriented stuff. (A tag lookup prior to jumping
to a subroutine, for example.) Granted, this is overhead, but we've used
generic procedures in hard real-time apps and have not found them to be
excessively slow. It also depends on exactly what you are doing. Some
generic parameters may impose less overhead than others. Could you post an
example of a generic parameter list that is causing you trouble?

There are three kinds of strings in Ada. The base level "primitive" strings
for which appendix A.4.3 provides a package of manipulation routines under
the name Ada.Strings.Fixed. These strings should be as fast as any other
language's strings given that they are a simple array implementation. Of
course, your compiler may have supplied a poor implementation of the package
Ada.Strings.Fixed, which could account for slow speed. The next type of
strings are defined in the package Ada.Strings.Bounded in A.4.4. This
variety of string should be based on a fixed size allocation and should also
perform at speeds similar to the Fixed string. You pay some space penalty
for semi-dynamic behavior, but not much time overhead. The third type of
string is the Unbounded string defined in A.4.5, Ada.Strings.Unbounded.
These will require some form of dynamic allocation as strings grow and
shrink. They provide far more convenient behavior at the expense of possible
wasted space and time overhead. Again, there may be performance problems
because of your particular implementation, so it will help to post your
environment and possibly some code fragments which you think are performing
poorly.

Another thing you might do is look for a compiler option that turns off
range checks on the code you believe is running too slow. This is like
performing on a high wire without a net, but once you've got confidence in
the correctness of your code, it will be less risky. You can also use the
pragma Suppress within your code to turn off a variety of checks which may
be slowing the code down. (See ARM 11.5)

Hope this helps.

MDC
--
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
***To reply, remove "bogon" from the domain name.***

Visit my web page at: http://www.mcondic.com/