[plt-scheme] contracts.ss: Can you disable them at runtime?

On Thu, May 17, 2007 at 08:44:22AM -0500, Robby Findler wrote:
>  Have you tried the "run mzc -k on my main file before each run" style
>  of development? Did you find it too slow then too? (DrScheme will
>  eventually (not soon, but eventually) do that kind of development for
>  you automatically, which is why I ask.)

Yes, but that means I don't get backtraces and other debugging aids.

If DrScheme is going to do that automatically, then I'd like to vote,
emphatically, for the bug that Ryan Culpepper submitted several months ago
in which he asked for various improvements to mzc.  (I'd cite the bug
number, but gnats isn't responding right now, so I can't look it up.)

I'll even go so far as to say that implementing automatic byte-code
compilation without addressing the issues in that bug report would largely
defeat the significant effort that PLT has put into debugging aids and
error reporting.

>  Also I hope you know that I did make the contracts generate much less
>  code a while back (speeding that up) -- I hope you're not remembering
>  old experiences?

It's possible; the most recent big problem would have been in January or
February.  I don't have the ability to check the actual compilation-time
experience in DrScheme right now, but as a rough indication, I did just
mzc-k one of the files for which this problem was most severe.  The .ss is
16K, the .zo is 784K.  When I disabled contracts [1] on the biggest set of
structure definitions, the .zo dropped to 125K.

Richard

[1]  I'm using the define-hierarchy/provide/contract form from Dave
     Herman's struct.plt planet package.  He provides a
     (without-hierarchy-contracts ...) form to disable contracts on the
     generated structures for precisely the reason that we're discussing.
     In the experiment above, I disabled contracts by adding this form to
     the file.

I recognize that a more rigorous experiment would involve removing the
define-hierarchy/provide/contract form and defining the hierarchy manually,
to remove one potential source of inefficiency.  Unfortunately, I don't
have time to investigate that further right now.  I'll happily make the
structure definitions available for those who want to look into this.