[plt-scheme] Disabling contract checking

From: Robby Findler (robby at cs.uchicago.edu)
Date: Mon Apr 10 17:18:58 EDT 2006

There have been performance improvements, here and there. It depends
when you last checked and what your contracts look like. Sorry I can't
say more.

Robby

At Mon, 10 Apr 2006 11:29:15 -0700, "Williams, M. Douglas" wrote:
> I concur that it would be nice to be able to turn it off.
> 
> I haven't checked recently, but when I first added contracts to the Science
> Collection I took an order of magnitude hit on performance with tight loops
> calling into a contract.  [This happened to be basically all of my
> examples.]  It was discussed on the mailing lists at the time.
> 
> I didn't use contracts for the differential equation solvers because they
> essentially always work that way.  However, I did leave all of the others in
> because I generally like the safer code.
> 
> I haven't checked on the performance between code with / without contracts
> recently.  Has there been any substantial change to improve performance?
> 
> Doug
> 
> > -----Original Message-----
> > From: plt-scheme-bounces at list.cs.brown.edu [mailto:plt-scheme-
> > bounces at list.cs.brown.edu] On Behalf Of Lauri Alanko
> > Sent: Monday, April 10, 2006 12:07 PM
> > To: plt-scheme at list.cs.brown.edu
> > Subject: [plt-scheme] Disabling contract checking
> > 
> > Contracts, though stupendously expressive, are still essentially just
> > "assert" on steroids. However, the reason why assertions are so
> > ubiquitously popular is that they can be disabled in production code,
> > removing all overhead. But am I blind, or is there really no such option
> > for contract.ss? Why?
> > 
> > I know that the theory is that contracts are placed only on inter-module
> > boundaries, and that inter-module boundaries are not crossed too often,
> > but neither of these is always true, so the unability to disable
> > contracts discourages one from placing precise contracts on
> > performance-critical functions. This seems like a shame.
> > 
> > What, in any case, would be the proper way to implement a compile-time
> > option such as this? A transformation-time parameter value? Or perhaps a
> > custom classloader that provides an alternate version of a
> > macro-defining module?
> > 
> > 
> > Lauri
> > _________________________________________________
> >   For list-related administrative tasks:
> >   http://list.cs.brown.edu/mailman/listinfo/plt-scheme
> _________________________________________________
>   For list-related administrative tasks:
>   http://list.cs.brown.edu/mailman/listinfo/plt-scheme


Posted on the users mailing list.