[racket] on the arity of the composition of procedures with different arities

From: Robby Findler (robby at eecs.northwestern.edu)
Date: Fri Nov 9 11:43:11 EST 2012

Re 3.: we should fix those, then.

:)

Robby

On Fri, Nov 9, 2012 at 10:40 AM, Eli Barzilay <eli at barzilay.org> wrote:
> I just measured the overhead again, to see if things changed.  The
> attached file has the exact implementation of the compose functions,
> and another copy with the proper reduction and renaming.  For the
> correct function I'm getting ~5x slowdown from the current code, which
> in turn is 20x slower than just using a lambda.  This is big enough to
> justify a comment saying something like "don't use this if you care
> about speed", which kind of makes the whole point of the function
> redundant.
>
> Notes:
>
> 1. Yes, the docs should say that already, but still I consider jumping
>    to a slowdown of two orders of magnitude as a major problem.
>
> 2. I'm not talking about a theoretical point here -- I *have* seen
>    `compose' used in tight loops, and I have personally written
>    explicit lambdas in code where I really should have just used it.
>
> 3. There are definitely other cases where things like `apply' are used
>    in a way that doesn't preserve arity, so it's not like this is an
>    exceptional problem (or a new one).
>
> 4. I'll shut up now.
>
>
> 20 minutes ago, Robby Findler wrote:
>> I think the right approach is to make the function behave correctly
>> first and then find the places to optimize second.
>>
>> In this case, using procedure-reduce-arity (or something else with
>> the same effect) is not merely "nice" but, IMO, necessary. That is,
>> we have procedure-arity in our PL and our primitives/core libraries
>> should respect that.
>
>
>
> --
>           ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
>                     http://barzilay.org/                   Maze is Life!
>

Posted on the users mailing list.