[racket-dev] Slow contracts

The issue is TR doesn't know statically know how the value will be
used, thus we have do the computation for determining the break even
point at run time. This puts the actual work in the contract system
(or at least the contracts that TR generates), and I don't understand
all the internal workings of these.

I do believe there are optimizations that we can do, for example
unrolling the contract so that only every 5 struct contracts is a lazy
chaperone contract. But I have no idea how we could dynamically pick
the best unrolling strategy.

On Thu, Jun 12, 2014 at 10:20 PM, Robby Findler
<robby at eecs.northwestern.edu> wrote:
> On Tue, Jun 10, 2014 at 2:27 AM, Eric Dobson <eric.n.dobson at gmail.com> wrote:
>> On Mon, Jun 9, 2014 at 9:46 PM, Eric Dobson <eric.n.dobson at gmail.com> wrote:
>>> Splitting this out because this is actually a different issue. This is
>>> about us generating slow contracts.
>>>
>>> There are two things in play here.
>>>
>>> One is that TR doesn't use the new lazy parts of struct/dc. This would
>>> require changing struct contracts from flat contracts to
>>> chaperone-contracts. Given that I think we are going to need to change
>>> struct contracts to sometimes be chaperone contracts anyways for
>>> soundness that might not be a huge loss.
>> I did performance measurements and it is about a factor of 60 slower
>> for lazy chaperone contracts. I see a couple of ways to improve these
>> numbers, so they could be better in the future with a bit more work on
>> optimizing. Given that strict contracts actually change the big O
>> notation I think that this is a reasonable performance price to pay,
>> given that data structures with more than 60 elements are fairly
>> common.
>
> Does it make sense to try to find the break-even point for a program
> that, say, makes two passes over the data-structure?
>
> Robby