guile-devel
[Top][All Lists]
Advanced

[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/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]