Newsgroups: comp.lang.scheme
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!barmar
From: barmar@think.com (Barry Margolin)
Subject: Re: Why memq vs memv vs member, etc.?
Message-ID: <1991May15.172635.18635@Think.COM>
Sender: news@Think.COM
Reply-To: barmar@think.com
Organization: Thinking Machines Corporation, Cambridge MA, USA
References: <1991May10.230057.15591@Think.COM> <chip.674143084@soi>
Date: Wed, 15 May 91 17:26:35 GMT

In article <chip.674143084@soi> chip@soi.UUCP (Chip Morris) writes:
>I agree with Mr. Margolin on the style and generality of his proposal.
>However, I just finished speeding up a large Common Lisp application
>in which using MEMQ was much faster than using MEMBER
>(with a :TEST of #'EQ) was quite significant.  The overhead of the
>additional parameters, especially keyword parameters, was alone enough
>to make a difference.  

I considered that before making my post.  However, my impression is that in
Scheme, performance is not as high a priority as style.

Also, Scheme designers expect the compiler to optimize away much of the
overhead.  In your test with Lucid, I think you may have forgotten to
enable some of the optimization capabilities, as Lucid knows how to
open-code calls to MEMBER when the :TEST option is #'EQ (I just tried it,
with optimization settings (speed 3), (safety 0), and (space 0); I looked
at the disassembly of (member x y :test #'eq) and it generated a simple
loop).  The Symbolics compiler also translates calls to many keyworded
functions into calls to internal versions that take positional arguments,
so that the keyword lookup is only done at compile time; however, this
isn't relevant to the kind of optimizations that a Scheme version would
need, since it doesn't have keyword parameters.

I guess the only problem with optimizing out the explicit passing of the eq
argument is that Scheme doesn't prohibit user programs from redefining
standard procedure names as Common Lisp does.  The compiler could turn off
the optimization if there were a lambda binding of eq, but it wouldn't be
able to detect whether a (set! eq ...) had been done.  Then again, this
problem exists with all open coding, and I assume most Scheme compilers do
open-code calls to many built in procedures (car, cdr, arithmetic, etc.).
And Schemers don't even have a valid excuse of "oh, the function position
is special", because one of the fundamental tenets of Scheme is that the
function position of a form is evaluated just like other positions.


-- 
Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar
