From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,f21b19265de84351 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1993-03-02 14:36:18 PST Newsgroups: comp.lang.ada Path: sparky!uunet!pmafire!news.dell.com!swrinde!sdd.hp.com!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!csn!csn!arrayb!wicklund From: wicklund@intellistor.com (Tom Wicklund) Subject: Re: Ada Embedded Systems Efficiencies Message-ID: <1993Mar2.223618.18978@intellistor.com> Organization: Intellistor, Inc. References: <1993Feb24.212146.13157@saifr00.cfsat.honeywell.com> Date: Tue, 2 Mar 93 22:36:18 GMT Date: 1993-03-02T22:36:18+00:00 List-Id: In <1993Feb24.212146.13157@saifr00.cfsat.honeywell.com> wisniews@saifr00.cfsat.honeywell.com (Joe Wisniewski) writes: >Anyone who has worked on an Ada embedded system program knows (or should know) that if the >system being built does not 'fit in the box', the system is not of much use to anyone. I >am involved in a very large Ada project where there is currently much concern about whether >or not we are going to 'fit in the box'. As a result as you can probably imagine, there >is an increasing amount of attention being paid to addressing "micro-efficiencies". This >attention takes on various forms: Remember Jon Bentley's comments in his Programming Pearls columns in CACM (and the books collecting those columns). As a rule, most execution time is spent in a small amount of the code. It's important to identify where the bottlenecks are and then decide to optimize those, whether by violating encapsulating functions, inlining code, using structures the compiler handles well, going to assembly language, or restructuring the code. Wholesale optimization won't do much more than obscure things and ensure that non-time critical code is blindingly fast. I've worked for many years with disk drives. It sometimes takes a while to get people to realize that other than read and write it doesn't matter how inefficient disk command implementations are (within reason, of course). There are also external factors to consider. For example, in my work with disk drives one must realize that timing is based on a disk revolution. It makes no sense to optimize code which will have to wait a full disk revolution (12-17ms) before it can do anything. Overlapping code with external factors (though it may sometimes obscure the structure a bit) gives a lot of "free" optimization since the time critical element is outside software control.