Re: Speeding up Ada procedure?

[Mark Johnson <mark_h_johnson@raytheon.com>]

Papandopulo wrote:
> 
> I have certain procedures dealing with
> large arrays which are potential performance
> bottlenecks. While they didn't cause
> performance problems yet I intuitively
> feel they will.
> 
Hmm. Have you tried measuring the performance of the routines in
question? I have found that my "intuition" (and others) fails to find
the real problem area more often than not. An example of some code I had
to fix was a Jovial to Ada translator. The developer knew that symbol
lookup needed to be fast so did a pragma (Inline) to speed it up. When I
fed a large file (say 3000 lines) with a lot of symbols, the program ran
really slow (over two CPU days - never finished). A profile did not find
the problem until I removed that pragma (Inline) and then 99.999...% of
the CPU time was in that symbol lookup routine.
 The lookup method was a linear search of an unsorted list!
We changed it to a hash table & the CPU time for that one file went to
less than 5 minutes.

Remember - measure before optimizing. Then fix the "right thing".

> Is it a way to remove runtime array
> bounds and other checks for particular
> procedure ?
> 
As several others have mentioned pragma (Suppress). However I don't
recommend it; like inline it may hide the real problem.

> While Ada checks are excellent on
> control-type part of program where is
> a lot of logic and not much time spent
> it can become deadly if massive arrays
> of data are being processed.
> 
I would not be so sure of that. Again you need to do the measurements.
If the arrays are as massive as you say they are - the compiler can do
the check of an index against the limit once or twice (say to the min /
max values of a loop) which is negligible overhead for a 1000 element
array. See what your compiler does or measure it before taking that
optimization step.

> If the procedure just takes an array and
> produces an array I can be sure it's not
> faulty by testing it with different size
> arrays and than turning off runtime checks.
> 
You would be better served by using Spark or some other proving system
before you make that decision.
  --Mark