Re: Why is Elisp slow?

[조성빈 <pcr910303@icloud.com>]

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 <spacibba@aol.com> 작성:
> 
> 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.