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,9da298537a16487e
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 1995-01-12 17:49:54 PST
Path: 
 nntp.gmd.de!Germany.EU.net!howland.reston.ans.net!news.sprintlink.net!news.clark.net!dsmith-ppp.clark.net!user
From: dsmith@clark.net (Doug Smith)
Newsgroups: comp.lang.ada
Subject: Re: Run-time checking and speed
Date: Thu, 12 Jan 1995 20:49:54 -0500
Organization: Consultant
Message-ID: <dsmith-1201952049540001@dsmith-ppp.clark.net>
References: <3ev16u$ojc@pong.lasc.lockheed.com>
 <3f0prq$3bq@theopolis.orl.mmc.com> <3f3deb$4us@gnat.cs.nyu.edu>
NNTP-Posting-Host: dsmith-ppp.clark.net
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Date: 1995-01-12T20:49:54-05:00
List-Id: <comp.lang.ada>

In article <3f3deb$4us@gnat.cs.nyu.edu>, dewar@cs.nyu.edu (Robert Dewar) wrote:

> T.E.D. says
> 
> "As for constraint checks, try to leave them in until your product is
> THOROUGHLY debugged. They are worth their weight in gold during the
> debugging phase."
> 
> [snip]
> 
> [snip...]to meet processing efficiency [...] you may have to abandon the
> checks, but do this only when you have to [...snip]
> 
> The penalty of run time checks can run anywhere from 5-50% depending on the
> code. [snip]
> 
> [snip]
> 
> Another situation where it is quite appropriate to turn off run time checks
> is in verified safety critical code where part of the verification ensures
> that the checks are not needed. You have to be *very* sure of your 
> verification technology to depend on this!

OK, some personal experience which has been verified countless times by
fellow engineers. A small percentage (10%) of the code accounts for (90%)
of the processing. In case after case, a dynamic analysis tool identifies
the code executed the most, the engineer optimizes and gets almost an order
of magnitude speed improvement.

In the old days (i.e. early compilers), I measured executable size differences
that showed half of the code was constraint checking (Today's compilers do
a much better job). By redesigning the code to explicitly check for and
raise the correct exceptions, I could then suppress the compiler generated
constraint checking.

Formal verification was helpful in increasing the confidence level of me and my fellow engineers; but since this was not a safety critical application, there weren't many arguments when they saw the performance results.

-- 
Doug Smith
dsmith@clark.net