@sorawee I was surprised that removing the contract from bitvector-ref reduced the runtime that much. In hindsight it makes sense, since bitvector-ref does little work per call and thus the cost of the contract is relatively large. Well spotted.

My understanding (could be wrong) is that contracts make chaperone, which inhibits many optimizations.

I wonder if provide/contract for simple function contracts could instead create a macro. If it is used as an identifier macro, then it creates a chaperone, but if it is immediately applied, then it doesn’t create a chaperone, but make special wrappers that checks preconditions and postconditions directly.

@sorawee it already does that

That doesn’t explain why switching from provide/contract to provide speeds things up so much, then.

The code that the contract library generates for the check is expensive, but doesn’t use a chaperone

I recommend looking at the expansion