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-03 20:26:58 PST Newsgroups: comp.lang.ada Path: sparky!uunet!gatech!howland.reston.ans.net!usc!sol.ctr.columbia.edu!The-Star.honeywell.com!saifr00.cfsat.honeywell.com!walls From: walls@saifr00.cfsat.honeywell.com (Gerald Walls) Subject: Re: Ada Embedded Systems Efficiencies Message-ID: <1993Mar3.143900.10592@saifr00.cfsat.honeywell.com> Organization: Honeywell Air Transport Systems Division References: <1993Feb24.212146.13157@saifr00.cfsat.honeywell.com> <1993Mar2.223618.18978@intellistor.com> Date: Wed, 3 Mar 93 14:39:00 GMT Date: 1993-03-03T14:39:00+00:00 List-Id: In article <1993Mar2.223618.18978@intellistor.com> wicklund@intellistor.com (Tom Wicklund) writes: >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. The problem here is not speed efficiency where you can selectively optimize. The problem is size optimization where it has to be done everywhere. We don't have the luxury of buying more memory but instead must make the code fit. gerald walls (walls@saifr00.cfsat.honeywell.com) or (int_walls@am.eccx.umc@esu36.cfsat.honeywell.com) Don't blame me. I voted Libertarian. How will you spend *your* middle-class tax cut? Any opinions expressed are my own and not those of Honeywell or its management.