From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?Q?=C3=93scar_Fuentes?= Newsgroups: gmane.emacs.help Subject: Re: Why is Elisp slow? Date: Mon, 06 May 2019 22:51:20 +0200 Message-ID: <87zhnz9uif.fsf@telefonica.net> References: <83tvebn1we.fsf@gnu.org> <20190503125832.44ovncaxp3vyjsla@Ergus> <20190504133218.g3ysx3ksuyvlthg3@Ergus> <831BD780-F954-4E23-BF31-ED4E135C919B@icloud.com> <20190506125848.okei2qrib7m5p3vx@Ergus> <20190506161757.wg4wy3vr7emxnciv@Ergus> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="56326"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Mon May 06 22:51:47 2019 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hNkaQ-000EWk-AT for geh-help-gnu-emacs@m.gmane.org; Mon, 06 May 2019 22:51:46 +0200 Original-Received: from localhost ([127.0.0.1]:33870 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hNkaP-0000ul-8h for geh-help-gnu-emacs@m.gmane.org; Mon, 06 May 2019 16:51:45 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:56771) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hNkaF-0000uc-7m for help-gnu-emacs@gnu.org; Mon, 06 May 2019 16:51:36 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hNkaD-0004CJ-8J for help-gnu-emacs@gnu.org; Mon, 06 May 2019 16:51:34 -0400 Original-Received: from [195.159.176.226] (port=59034 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hNkaB-0004An-8p for help-gnu-emacs@gnu.org; Mon, 06 May 2019 16:51:32 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.89) (envelope-from ) id 1hNka8-000EAv-4q for help-gnu-emacs@gnu.org; Mon, 06 May 2019 22:51:28 +0200 X-Injected-Via-Gmane: http://gmane.org/ Cancel-Lock: sha1:6RalzMEbBH31jULm7Vh3wIWr8zE= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 195.159.176.226 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.org gmane.emacs.help:120239 Archived-At: Stefan Monnier writes: > I totally agree with the sentiment; we'd benefit from "out-sourcing" the > maintenance of the language implementation, but we can't just replace > Elisp with something else, so we need to find another well-maintained > Elisp implementation that's at least as good as that we have now. > > AFAIK the options are: > - Keep what we have > - Move to Guile > - Move to CLISP > - Move to SBCL - Pick an Elisp subset that can be compiled to efficient machine code and has a runtime model that is amenable to C. You retain much of the benefits of Elisp but gain fast execution and the possibility of using a miriad of libraries. Of course, do not replace Elisp with this, use it just when it matters. There are several C-with-a-Lisp-coat implementations out there. I have one (not public) and know that this method works. > Another approach would be to implement an Elisp-to-JS compiler and > then use one of the heavily-optimized JIT-compilers for JS. > Compiling Elisp to JS should be much easier than compiling to > native code. Javascript's JITs seem fast because the interpreters are so slow. Those JITs only provide near-C code efficiency only on selected cases. Translating Elisp to JS does not inspire much confidence about the efficiency of the resulting machine code, not to mention the required work to interface with current Emacs C base and external libraries.