From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.5-pre1 Date: 26 Feb 93 05:59:18 GMT From: alex@MIMSY.CS.UMD.EDU (Alex Blakemore) Subject: Re: Ada Embedded Systems Efficiencies Message-ID: <64621@mimsy.umd.edu> List-Id: > 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