Re: Elisp performance

[Ken Raeburn]

On Aug 4, 2009, at 11:47, Andy Wingo wrote:
> > In any case, because of dynamic scoping and the expected behaviour of
> > flet to change possibly primitives during its extent, I think we  
> > can't
> > do anything like that for Elisp (except providing guile-primitive for
> > hand-optimizing such calls).
>
> Hmmmmmm. It seems that Emacs does inline, but it also reacts to flet.

Which Emacs are you using here?  I'm using one of the pretest versions  
of GNU Emacs 23, and also tried 22.1, and both gave me different  
results from yours.

> ELISP> (defun add (x y) (+ x y))
> add
> ELISP> (compile-defun 'add)
> nil

Documentation says:
---
compile-defun is an interactive compiled Lisp function in
`bytecomp.el'.

(compile-defun &optional arg)

Compile and evaluate the current top-level form.
Print the result in the echo area.
With argument arg, insert value in current buffer after the form.
---

So, the argument isn't a symbol to byte-compile the function  
definition of; it's just a flag.
I used (byte-compile 'add).

> ELISP> (disassemble #'add)
> byte code for add:
>  args: (x y)
> 0       varref    x
> 1       varref    y
> 2       plus
> 3       return

I got the same disassembly.

> ELISP> (require 'cl)
> cl
> ELISP> (flet ((+ (x y) (- x y))) (add 10 20))
> -10

It prints 30 for me.

> How does this work? Ken do you know?

My guess would be that the bytecode interpreter in your version is  
hardcoded to look up the function value of "+" and call it.  In Emacs  
23 (and apparently 22.1), it calls the C function Fplus (which is the  
default function binding for the symbol "+"); it doesn't check to see  
if "+" has been redefined.

Ken