Re: Checks off for release code - was Re: Size code Ada and C

[eachus@spectre.mitre.org (Robert I. Eachus)]

In article <dewar.899387741@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:

 > One more comment on polls with respect to checks off for the release code.
 > Here again, market input is important. If one found that everyone turns
 > off checks for delivery, then an implementor might decide to put in less
 > effort in removing redundant checks. I think for example that Alsys,
 > anticipating that everyone would keep checks on, put huge effort into
 > removing redundant checks that might have been better expended in retrospect
 > on better optimization in general.

    I've worked on several embedded projects which got to the point of
having the "checks on/checks off" debate.  My usual suggestion was to
recompile with all checks off, and do a quick test.  (Usually this
code obviously failed several key tests.)  At the same time we
profiled the code, then chose particular high CPU time units and did
differential testing to determine the improvement in each from turning
checks off.

   After a week or two, in every case less than a month, we had a
version with checks off in about 5% of the units which outperformed
the version with all checks off.  This eventually became the baseline
for formal testing.

   Usually what we saw was five to ten percent performance changes in
individual units, and by choosing all of the tested units with no
harmful effects from turning checks off and a net positive effect on
the performance, we could get a 3% or so overall performance
enhancement.   About ten to fifteen percent of all units should not be
compiled with checks off because the logic will fail.

   With earlier versions of GNAT, this behavior was skewed by the slow
handling of what used to be Numeric_Errors.  So there were a very few
units compiled with -gnato.
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...