Re: Ada Embedded Systems Efficiencies

[alex@MIMSY.CS.UMD.EDU (Alex Blakemore)]

> I am concerned that "good design" macro-efficiencies are going to be "un-done
"
> due to perceived net overall gain of over-implementing micro-efficiencies.
> In short, many Ada object-oriented concepts are being 'questioned'; i.e. data
> encapsulation, private types usage, call-through procedures;

Most or all of any additional overhead associated with the
techniques you mention can be avoided by proper use of pragma
inline. For large procedures this might explode code size, but dont
avoid it because of this. For small subprograms that access private
type components or serve as call throughs, there should be little
effect in code size.

If what your coworkers are doing is replacing private types with non
private types and access routines with direct references and call
through procedures with the eventual call, then pragma inline will
achieve exactly the same effect.

In the worst case, you could be expending lots of manual effort,
introducing errors, and making the system much less maintainable
with absolutely no gain.  The exact same result performance wise
could be obtained safely with much less trouble without changing the
design or affecting the maintainability by adding some pragmas.

If your backend doesnt implement this pragma, that would be a good
place to expend some effort.

There are a few things to watch out for. Pragma inline introduces a
dependency upon the package body that may cause circular
dependencies in a few cases, and longer recompilation times in many.
For this reason, I suggest adding the pragma to make sure you dont
generate an illegal dependency (the compiler should tell you if you
do) and then commenting it out while you are still developing the
unit body (to allow faster recompilation). Then you can uncomment
the pragma when you get into integration and test.

> Note: Very little prototyping was done and as a result effective
early > timing studies were not available or used.

Isnt it dangerous to make radical changes based on so little
information?  Serious benchmarks are useful and take alot of care;
but it isnt hard at all to get ball park measurements with very
little effort.  Perhaps you could convince people to measure a few
important aspects of the system before investing alot of time
optimizing the wrong component in the wrong way?







-- 
---------------------------------------------------
Alex Blakemore alex@cs.umd.edu   NeXT mail accepted