[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Why is Elisp slow?

From: 조성빈
Subject: Re: Why is Elisp slow?
Date: Tue, 7 May 2019 22:43:24 +0900

Thinking about this, instead of SBCL (which is super-fast, but imposes 
restrictions on functions being called from the outside world), why not embed 
ECL (Embeddable Common Lisp), which 
* is significantly slower than SBCL, about 2~3x slower? but is still much 
faster than Elisp.
* compiles CL code to C
* has great interoperability with C (have never done this before :-( but based 
on what I hear, can both freely call CL functions from C and the other way 
around, generate C inside CL as a ECL extension, etc, etc…)

Looks like if Emacs code has Elisp & C interwined, ECL might be a better shot?

> 2019. 5. 7. 오후 10:14, Ergus <address@hidden> 작성:
> On Tue, May 07, 2019 at 09:04:31AM -0400, Stefan Monnier wrote:
>>>> Similarly, you'll need to rewrite all the functions/macros like CONSP,
>>>> SYMBOLP, FIXNUMP, XCAR, XCDR, make_fixnum, ...  Performance of those
>>>> is important.
>>> Why would you not use the default CL???s defun, car, cdr, symbol-p,
>>> cons-p, etc, etc?
>> I'm talking the work needed to adapt Emacs's C code, e.g:
>>   DEFUN ("get-buffer-window", Fget_buffer_window, Sget_buffer_window, 0, 2, 
>> 0,
>>          doc: /* Return a window currently displaying BUFFER-OR-NAME, or nil 
>> if none.
>>   BUFFER-OR-NAME may be a buffer or a buffer name and defaults to
>>   the current buffer.
>>   The optional argument ALL-FRAMES specifies the frames to consider:
>>   - t means consider all windows on all existing frames.
>>   - `visible' means consider all windows on all visible frames.
>>   - 0 (the number zero) means consider all windows on all visible
>>       and iconified frames.
>>   - A frame means consider all windows on that frame only.
>>   Any other value of ALL-FRAMES means consider all windows on the
>>   selected frame and no others.  */)
>>        (Lisp_Object buffer_or_name, Lisp_Object all_frames)
>>   {
>>     Lisp_Object buffer;
>>     if (NILP (buffer_or_name))
>>       buffer = Fcurrent_buffer ();
>>     else
>>       buffer = Fget_buffer (buffer_or_name);
>>     if (BUFFERP (buffer))
>>       return window_loop (GET_BUFFER_WINDOW, buffer, true, all_frames);
>>     else
>>       return Qnil;
>>   }
>> -- Stefan
> That's why I was wondering about the C binds and the C types
> representations in SBCL more than the lisp part of the implementation.

reply via email to

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