[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Elisp performance
From: |
Andy Wingo |
Subject: |
Re: Elisp performance |
Date: |
Tue, 04 Aug 2009 21:28:52 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.0.92 (gnu/linux) |
On Tue 04 Aug 2009 18:12, Ken Raeburn <address@hidden> writes:
> 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.
I'm using GNU Emacs 23.0.92.1 (i686-pc-linux-gnu, GTK+ Version 2.16.0)
of 2009-04-04
Something from git anyway.
>> 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).
Ahhhhh. Indeed now it prints 30 for me.
>> 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.
It appears "disassemble" actually compiled the function first, without
altering the defun.
>> 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.
Yes I saw this, but was led astray via compile-defun ;)
Thanks, this shows that we can open-code primitives without worrying
about flet.
Cheers,
Andy
--
http://wingolog.org/
- Re: Elisp performance, Andy Wingo, 2009/08/04
- Re: Elisp performance, Andy Wingo, 2009/08/04
- Re: Elisp performance, Andy Wingo, 2009/08/04
- Re: Elisp performance, Andy Wingo, 2009/08/04
- Re: Elisp performance, Andy Wingo, 2009/08/04
- Re: Elisp performance, Andy Wingo, 2009/08/04
- Re: Elisp performance, Andy Wingo, 2009/08/04