[racket] profiling

I have not tried to profile anything to be sure that I understand what
Neil T was talking about, but my experience trying to speed up
contracts in the past has led me to believe that most of the slowdown
is in creating the wrappers, not checking the predicates (at least for
contracts that are close to what types can do, which seems to be
common). In our current implementation, dependent contracts exacerbate
this because they force us to do the wrapper creation later.

Robby

On Sat, Nov 12, 2011 at 9:20 AM, Greg Hendershott
<greghendershott at gmail.com> wrote:
>>  - higher-order contracts and contract regions are slow
>
> If Neil van Dyke is reading this, I think this would be an excellent
> topic for your book. What are practical ways to get the benefits of
> contracts during development, while minimizing or eliminating their
> cost in production?  Is it as simple as "rebuilding" with versions of
> define/contract et al that don't actually create contracts?  Any other
> strategies?
>
> I also wonder if Racket could support a runtime switch. Could there be
> a parameter like `ignore-contracts?' that the contract wrapper
> functions check, and possibly just directly call the wrapped function.
> (This is a bit of a compromise. It wouldn't be quite as fast as the
> case of rebuilding with no contract wrappers at all. And it would
> actually add a tiny bit more overhead to the case where contracts are
> being used. But it might be a really good compromise.)
>
> P.S. I love Matthew's article about Racket as a programming language
> programming language. That is one of Racket's key differentiating
> features. Contracts is something else quite special about Racket
> (compared to a lot of popular languages) and something Racket does
> (almost; see above) exactly right.  I realize contracts are not as
> sexy as DSLs, and I understand about Typed Racket as another vision
> for the future. But I think contracts is something that is more
> special and a stronger selling point than you may appreciate if you've
> been around PLT for many years.
>
> On Thu, Nov 10, 2011 at 2:50 PM, Neil Toronto <neil.toronto at gmail.com> wrote:
>> Expanding on what Robby said about the statistical profiler (the `profile'
>> module) being more useful: I've found that the statistical profiler more
>> often correctly reports the names and source locations of functions. It also
>> doesn't require compiling your code with profiling enabled - it just works.
>> It doesn't do the nice graphical stuff, so you'd have to learn how to read
>> its textual output.
>>
>> Anyway, if you get stuck because the graphical profiler can't tell you a
>> source location, try the statistical one.
>>
>> FWIW, I've just done a major bout of profiling and speed tweaking in the
>> plot library (managed 2x-5x faster on everything), and I've discovered that:
>>
>>  - for/* macros are fairly fast
>>  - match and match-define are very fast, as well as being very readable
>>   (this is ace: you almost can't lose by destructuring with match)
>>  - function application is not generally a big performance hit
>>  - higher-order contracts and contract regions are slow
>>
>> Neil T
>>
>> On 11/10/2011 08:47 AM, Adam Shaw wrote:
>>>
>>> Excellent! This is very helpful -- thanks!
>>>
>>> Regards,
>>>
>>> Adam
>>>
>>> On Nov 10, 2011, at 9:44 AM, Robby Findler wrote:
>>>
>>>> Turning on profiling is an action in the Language dialog. It needs to
>>>> be set up before your program is compiled (which the below doesn't
>>>> do).
>>>>
>>>> Robby
>>>
>>> _________________________________________________
>>>   For list-related administrative tasks:
>>>   http://lists.racket-lang.org/listinfo/users
>>
>> _________________________________________________
>>  For list-related administrative tasks:
>>  http://lists.racket-lang.org/listinfo/users
>>
>
> _________________________________________________
>  For list-related administrative tasks:
>  http://lists.racket-lang.org/listinfo/users
>