[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 <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.
- Re: Why is Elisp slow?, (continued)
- Re: Why is Elisp slow?, Jean-Christophe Helary, 2019/05/06
- Re: Why is Elisp slow?, Ergus, 2019/05/06
- Re: Why is Elisp slow?, Ergus, 2019/05/06
- Re: Why is Elisp slow?, Ergus, 2019/05/07
- Re: Why is Elisp slow?, 조성빈, 2019/05/07
- Re: Why is Elisp slow?, Ergus, 2019/05/07
- Re: Why is Elisp slow?, Stefan Monnier, 2019/05/07
- Re: Why is Elisp slow?, 조성빈, 2019/05/07
- Re: Why is Elisp slow?, Stefan Monnier, 2019/05/07
- Re: Why is Elisp slow?, Ergus, 2019/05/07
- Re: Why is Elisp slow?,
조성빈 <=
- Re: Why is Elisp slow?, Stefan Monnier, 2019/05/07
- Re: Why is Elisp slow?, Ergus, 2019/05/07
- Re: Why is Elisp slow?, Ergus, 2019/05/09
- Re: Why is Elisp slow?, 조성빈, 2019/05/09
- Re: Why is Elisp slow?, Ergus, 2019/05/10
- Re: Why is Elisp slow?, 조성빈, 2019/05/10
- Re: Why is Elisp slow?, tomas, 2019/05/10
- Re: Why is Elisp slow?, 조성빈, 2019/05/07
- Re: Why is Elisp slow?, Ergus, 2019/05/07
- Re: Why is Elisp slow?, Óscar Fuentes, 2019/05/06