Here is a graphical example where you can see the difference in speed. The life-bitblt-slower.ss requires matrix-slower.ss (with ->d and no bounds checking in the body of the code) and is really slow. The life-bitblt-faster.ss requires matrix-faster.ss (with -> and bounds checking in the body of the code) and performs okay. Other than the contract and the corresponding presence or ansence of bounds checking (to give the same functionality), the code is identical. [The only difference between life-bitblt-slower.ss and life-bitblt-faster.ss is the require statement.] They all do better compiled. But it interesting to see the speed difference. Note that the code used the science and animated-canvas collections from PLaneT and will download them the first time any of them are run, which takes some time. I sent a response that also includes a version that doesn't use the matrix abstraction at all (and therefore no contracts) that is much faster that the 'faster' version here. You'll get it when/if the moderator releases it. Doug <div class="gmail_quote">On Sat, Apr 11, 2009 at 1:55 PM, Robby Findler <<a href="mailto:robby@eecs.northwestern.edu">robby@eecs.northwestern.edu</a>> wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> ->d actually evaluates the expressions (and/c exact-nonnegative-integer? (</c (matrix-rows matrix))) each time you call the function, and that evaluation involves building up a contract combinator (and doing various error checking) before actually checking the contract. That's where the extra overhead comes from. In comparison with the -> contract, all of that work is done once, before the contract is even attached to the value. I have experimented with various optimizations to avoid this work, but there is a lot to do to make that happen. Robby </blockquote></div>