[Top][All Lists]

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

Re: Why is Elisp slow?

From: Ergus
Subject: Re: Why is Elisp slow?
Date: Tue, 7 May 2019 15:14:42 +0200
User-agent: NeoMutt/20180716

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 ();
       buffer = Fget_buffer (buffer_or_name);

     if (BUFFERP (buffer))
       return window_loop (GET_BUFFER_WINDOW, buffer, true, all_frames);
       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]