[racket] profiling

From: Greg Hendershott (greghendershott at gmail.com)
Date: Sat Nov 12 10:20:16 EST 2011

>  - 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
>



Posted on the users mailing list.