Re: [Maxima-discuss] (MEMBER ...) with literal symbol(s)

Raymond Toy <[email protected]> Fri, 2 May 2025 10:18:47 -0700
Newsgroups	gmane.lisp.gcl.devel,gmane.comp.mathematics.maxima.general
Message-ID	<[email protected]>
This is a multi-part message in MIME format.
--------------0oaMt0etHPFutG0bLpjKQtDV
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit


On 5/2/25 8:56 AM, David Scherfgen wrote:
> eq is a single machine instruction in most Lisp implementations and is 
> inlined, i.e. doesn't require a function call.
> In contrast, eql is usually not inlined - it incurs the overhead of a 
> function call and performs additional type checks if eq returns nil.
> Some experiments with SBCL show a factor ~10 difference in performance 
> between eq and eql.
>
> Does it matter within Maxima? Maybe. member is called extremely often, 
> and during a test suite run, it's the top #7 function where time is 
> being spent.
> Maxima basically uses member as a short way of writing:
>
> (or (eq ...) (eq ...) ...)
>
> I'd argue that in this long-form, if we know we're working with 
> symbols, we would definitely use eq, not eql. So if we optimize for eq 
> in long-form code, shouldn't we be just as deliberate when using member?

I'm not sure we are (were) actually really deliberate about using `eq` 
instead `eql`.  Some of the code is really,  really old.

But I have no issues with replacing appropriate calls to `member` with 
`memq` instead.  That makes it clearer we really do want `eq` and, if 
needed, we can supply a compiler macro to further optimize the calls, as 
needed.


--------------0oaMt0etHPFutG0bLpjKQtDV
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    <link id="MDHR_textcomplete" rel="stylesheet"
href="moz-extension://53f66b0d-8360-4eab-9731-62bf0d7556e8/vendor/textcomplete.css">
  </head>
  <body>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 5/2/25 8:56 AM, David Scherfgen
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAMTHLKhdOMKfj+HbHOUeU8ztOuknTLKCR3kTKd569YZd7wa+YQ@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr"><font face="monospace">eq</font> is a single
        machine instruction in most Lisp implementations and is inlined,
        i.e. doesn't require a function call.
        <div>In contrast, <font face="monospace">eql</font> is usually
          not inlined - it incurs the overhead of a function call and
          performs additional type checks if <font face="monospace">eq</font>
          returns <font face="monospace">nil</font>.</div>
        <div>Some experiments with SBCL show a factor ~10 difference in
          performance between <font face="monospace">eq</font> and <font
            face="monospace">eql</font>.</div>
        <div><br>
        </div>
        <div>Does it matter within Maxima? Maybe. <font
            face="monospace">member</font> is called extremely often,
          and during a test suite run, it's the top #7 function where
          time is being spent.</div>
        <div>Maxima basically uses <font face="monospace">member</font>
          as a short way of writing:</div>
        <div><br>
        </div>
        <div><font face="monospace">(or (eq ...) (eq ...) ...)</font></div>
        <div><br>
        </div>
        <div>I'd argue that in this long-form, if we know we're working
          with symbols, we would definitely use <font face="monospace">eq</font>,
          not <font face="monospace">eql</font>. So if we optimize for
          <font face="monospace">eq</font> in long-form code, shouldn't
          we be just as deliberate when using <font face="monospace">member</font>?</div>
      </div>
    </blockquote>
    <p>I'm not sure we are (were) actually really deliberate about using
      `eq` instead `eql`.  Some of the code is really,  really old.</p>
    <p>But I have no issues with replacing appropriate calls to `member`
      with `memq` instead.  That makes it clearer we really do want `eq`
      and, if needed, we can supply a compiler macro to further optimize
      the calls, as needed.<br>
    </p>
    <br>
    <ul class="dropdown-menu textcomplete-dropdown"
      style="display: none; position: absolute; z-index: 1000;"
      contenteditable="false">
    </ul>
  </body>
</html>

--------------0oaMt0etHPFutG0bLpjKQtDV--