From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.help Subject: Re: Is Elisp really that slow? Date: Sun, 12 May 2019 17:01:02 -0400 Message-ID: References: <20190502214006.4fdsinp7u5xuqvdv@Ergus> <20190503004416.xfuzzucflp6bxpuz@Ergus> <8736lm30lz.fsf@web.de> <864l61j04d.fsf@zoho.eu> <20190511073254.GB29829@tuxteam.de> <04187AB9-AD7D-492D-A890-BCB01848370C@icloud.com> <20190511075712.GD29829@tuxteam.de> <86a7fsfv1m.fsf@zoho.eu> <20190512075448.GA11650@tuxteam.de> <346107E9-590D-4A18-9152-ECFF36FC4EDC@icloud.com> <83r293bvok.fsf@gnu.org> <87ef53vihw.fsf@telefonica.net> <83mujrbsk7.fsf@gnu.org> <87a7frvfo1.fsf@telefonica.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="81879"; 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 Sun May 12 23:07:15 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 1hPvgh-000L9f-1u for geh-help-gnu-emacs@m.gmane.org; Sun, 12 May 2019 23:07:15 +0200 Original-Received: from localhost ([127.0.0.1]:47297 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hPvge-0000no-SO for geh-help-gnu-emacs@m.gmane.org; Sun, 12 May 2019 17:07:12 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:51977) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hPvgR-0000ml-FE for help-gnu-emacs@gnu.org; Sun, 12 May 2019 17:07:00 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hPvas-0002Fz-R8 for help-gnu-emacs@gnu.org; Sun, 12 May 2019 17:01:15 -0400 Original-Received: from [195.159.176.226] (port=40622 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hPvas-00026Q-JB for help-gnu-emacs@gnu.org; Sun, 12 May 2019 17:01:14 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.89) (envelope-from ) id 1hPvap-000DsK-8z for help-gnu-emacs@gnu.org; Sun, 12 May 2019 23:01:11 +0200 X-Injected-Via-Gmane: http://gmane.org/ Cancel-Lock: sha1:Wivr33lGRBroH2TFWZThlOu6Cp4= 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:120327 Archived-At: >> I agree that our situation with IDE features is quite bleak, but >> that's entirely unrelated to the issues discussed in this thread, and >> its reasons IMO have nothing to do with either ELisp speed or >> flexibility of Emacs in general. > > It has a lot to do. Analyzing source code is cpu-intensive, because it > is algorithmically complex and lots of data needs to be processed. That's part of the problem, but I think it's a minor part of it: most successful IDEs talk directly to the compiler instead of reimplementing their own language-implementation-front-end (that requires changes to the compiler, admittedly, but that's what the `I` is all about). IOW besides performance, another big challenge is having to (re)implement a complete language front-end. I think that's why no effort in this direction took off until LSP: without LSP, providing IDE-like features in Emacs requires either hacking your compiler so it gives Emacs the relevant info (this has been done for a few languages where Emacs users represent a large part of the population (Lisp and Agda come to mind), but it's rather rare), or reimplementing a front-end which is hard to justify (and requires a lot of up-front work before you get any benefit at all). Most major modes have just enough manpower to get a highlighter and basic indenter up and running with incremental improvements after that. Of course, the fact that performance may get in the way makes this even less attractive. > Even if you defer the actual analysis to an external tool (which is the > sane thing to do, BTW) Indeed. > the amount of data to be processed on the Emacs end can be quite > large, more than enough to introduce perceptible delays that spoil > the experience. With LSP front-ends using the C-implemented json parser present in recent Emacsen, this should hopefully be less problematic, but indeed this is a part where we need to put some of the code in C in order to get good enough performance. And the single-threadedness is an additional issue in this respect. Stefan