[racket] TR memory optimization: 240 Bytes of garbage for calling TR?

If you need a quick fix to get things going for your class, you might
consider just doing things unsafely (with a few checks where you know
they are needed). Don't use TR and then you don't get the contracts,
and you can probably get the allocation down.

Robby

On Sun, Nov 11, 2012 at 5:40 PM, John Clements
<clements at brinckerhoff.org> wrote:
>
> On Nov 11, 2012, at 1:57 PM, Matthias Felleisen wrote:
>
>>
>> On Nov 11, 2012, at 2:48 PM, John Clements wrote:
>>
>>>>
>>>> I'm not sure why this would be.  Is the code students write unrestricted?
>>>
>>> Pretty much, yes. So, for instance, a student might write:
>>>
>>> (signal-play
>>> (network ()
>>>         [s ((looper song2))]
>>>         [ctr ((loop-ctr 0 1))]
>>>         [on? (toggle ctr)]
>>>         [out (reverb s)]))
>>>
>>> where the signals take on float, boolean, or any kind of value. This expands into something containing this "inner loop" procedure:
>>>
>>> (lambda ()
>>> (define s (n1))
>>> (define ctr (n2))
>>> (define on? (toggle ctr))
>>> (define out (reverb s))
>>> (set! saved-s s)
>>> (set! saved-ctr ctr)
>>> (set! saved-on? on?)
>>> (set! saved-out out)
>>> out)
>>>
>>> It would be pretty hard to assign types any tighter than "any" to these rhs expressions.
>>
>>
>> John, are the students really writing code w/o constraints? Would it be much of an imposition to ask for base types?
>
> I think it depends on the setup. In my case, I'm trying to add a reverb unit for a class that's about 8 weeks into an 11-week semester. Retrofitting types to the system would be bold at this point, even for me :).  For next year? maybe. I have to say that my experiences thus far with TR have taught me to be a bit careful, though. I would want to experiment with such a setup before deploying it.
>
> John
>