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=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,9a0ff0bffdf63657 X-Google-Attributes: gidfac41,public X-Google-Thread: f43e6,9a0ff0bffdf63657 X-Google-Attributes: gidf43e6,public X-Google-Thread: 1108a1,9a0ff0bffdf63657 X-Google-Attributes: gid1108a1,public X-Google-Thread: 103376,4b06f8f15f01a568 X-Google-Attributes: gid103376,public From: eachus@spectre.mitre.org (Robert I. Eachus) Subject: Re: Optimizing recursion (was Re: Why C++ is successful) Date: 1998/08/26 Message-ID: #1/1 X-Deja-AN: 384952294 References: <6qfhri$gs7$1@nnrp1.dejanews.com> <35cb8058.645630787@news.ne.mediaone.net> <902934874.2099.0.nnrp-10.c246a717@news.demon.co.uk> <35E32841.49A5343D@fv.com> Organization: The Mitre Corp., Bedford, MA. Newsgroups: comp.lang.eiffel,comp.object,comp.software-eng,comp.lang.ada Date: 1998-08-26T00:00:00+00:00 List-Id: In article <35E32841.49A5343D@fv.com> Darren New writes: > Why wouldn't the compiler just generate the best code that is > sematically equivalent to the Ada source? Why does the author of the > code have to tell the compiler that the *author* thinks it's more > efficient to expand the routine inline than to call it as a function? Because there is more than semantic equivalence involved. If a subprogram is called in the same source file, of course the compiler should figure out whether it is better to inline the code. In that case, the pragma acts as a hint as to whether the programmer prefers time or space optimization. But in the more normal case, at least more normal in Ada, the called function is in a different compilation unit, and inlining the code will cause effects visible to the programmer of the calling program if the implementation of the called abstraction changes. (In Ada, the environment requires that you recompile the caller if that happens, in some other languages you use tools like make to get the same effect.) So the pragma indicates that the author of abstraction feels that he has the bugs out, and the code won't change often if at all. In fact one indication of poor software engineering on Ada projects is when managers complain about compilation speeds or recompilation times. If programmers are making small changes that require fifty thousand line recompiles, no compiler is going to be acceptably fast. That is when premature use of Inline, or putting initial values in package specifications that aren't really constants, and all other sources of extra coupling need to be found and fixed. I bring this up becuase it is one of those things that you normally don't think of in advance, but once you see it, you use it all over the place: function Max_Name_Length return Positive; ... function Max_Name_Length return Positive is begin return 120; end Max_Name_Length; may seem like a lot of extra work compared to: Max_Name_Length: constant Positive := 120; but it limits the amount of code that may have to be changed. Later on you can go in and add the pragma Inline, or use a compiler option to do agressive inlining. But in the meantime, if the value fluctuates from 120 to 110 to 132, you don't have to recompile anything other than the one file that changed. You can even go further, and read the value from a file if necessary. (Read if managment can't make up their minds.) In Ada, it costs very little effort, and usually no execution time, to treat not quite constants by providing inquiry functions like this. In other languages, these values are either global variables, and no optimization is possible, or global constants and you get hit with the recompile costs. (Or worse, you forget one case where there is a dependency...) -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is...