From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Lynn Winebarger Newsgroups: gmane.emacs.devel Subject: Re: Why tree-sitter instead of Semantic? (was Re: CC Mode with font-lock-maximum-decoration 2) Date: Fri, 12 Aug 2022 08:37:25 -0400 Message-ID: References: <83o7wuva9o.fsf@gnu.org> <83mtceupbx.fsf@gnu.org> <83lerxvfnu.fsf@gnu.org> <838rnxvdcq.fsf@gnu.org> <83r11ptksn.fsf@gnu.org> <83a68dti6w.fsf@gnu.org> <874jykzvx9.fsf@yahoo.com> <83fsi4sttn.fsf@gnu.org> <838rnws5c7.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37674"; mail-complaints-to="usenet@ciao.gmane.io" Cc: luangruo@yahoo.com, acm@muc.de, emacs-devel@gnu.org, monnier@iro.umontreal.ca, Yuan Fu To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Aug 12 14:38:52 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oMTwC-0009ZK-EK for ged-emacs-devel@m.gmane-mx.org; Fri, 12 Aug 2022 14:38:52 +0200 Original-Received: from localhost ([::1]:34878 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oMTwB-0005k7-9g for ged-emacs-devel@m.gmane-mx.org; Fri, 12 Aug 2022 08:38:51 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45370) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oMTv5-0004u0-BP for emacs-devel@gnu.org; Fri, 12 Aug 2022 08:37:43 -0400 Original-Received: from mail-pj1-x1030.google.com ([2607:f8b0:4864:20::1030]:44839) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oMTv3-0002sk-J5; Fri, 12 Aug 2022 08:37:43 -0400 Original-Received: by mail-pj1-x1030.google.com with SMTP id e8-20020a17090a280800b001f2fef7886eso793093pjd.3; Fri, 12 Aug 2022 05:37:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=NrE4P1kH8sZd9pGhXLwtn2b07JF/og3xJk08pgnenEo=; b=Z3A+doqOhTkmx7bLKo/tvec6Z8p7GgIoIiSL0oL3zxaFeitisNUSGMo83OSnIQ+zeg ZA+PHhz+rZYV12Px6UeKgRfTgayB9fHWpKy8j+gFDtEonS/XsKj8czPWH4ETYM9OwwR2 9KiAd3VKZyIPFcHqbs4rm7pHfrUZnvbDFB85FkFdCHsu9LcSkGC61Bh7X1SoIIqohjfE qGGLchx5zfIkVcF7DgbbyFeMndOGA8K3dae9YiV7Oauqocyz8EML1ZNdUM/yEDk28QL3 F7ChLJksDRHASeyM3sHNFhpsPODMau/jMbWDVjEGaZteRkDBo3Tr79ddcgddjUzF5UDH VpWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=NrE4P1kH8sZd9pGhXLwtn2b07JF/og3xJk08pgnenEo=; b=NA48gqp7izn78lXVP+3Cwd9v7W4PVtSfhxXviFjLrM9X5pHr0WdFq6S8YzRtoF4W8+ ELQ32gIvQIXOTDUYcxhK5vs1SzqnqqwWAim6y40whAZhQeLbfUzsT7cwm1uyCuivOI5G vZg5/cYsX6J9yoWitPhJNC5EvR2HmptYNTTWMXDVQzV+M9b7mZze065wN2dsOsJFBnvU dWimuuX6r4JQ+cNSSGV4aIZLb4uJsdRgXqlUZ8URuK5qPOfkXxUFXks8io/S1dH8lZ+u sIl8gzmo7HJuY/LPIgaHAj2jDMol9ihfDjo0tr0eUjAivcQSw5G63IOIaBnxUx350m56 IsCg== X-Gm-Message-State: ACgBeo1D629O3X9fpN7FxLSA0IxxzNUhaUPFuzcpCQSulTLXRU5XbmAx WhOBF+DHE4RePuJNA8vAyanP19NtmTVbpQtsm6AGi1dR X-Google-Smtp-Source: AA6agR6QSL9xtpPWeCi2Y/7/7poUDtrp5iBt5tmiFwP1ZOizz8FDJDMtQMAs1LIkNo2dDDFUuxwu8HWHtxP4ttE52M0= X-Received: by 2002:a17:902:e30c:b0:171:2036:532c with SMTP id q12-20020a170902e30c00b001712036532cmr3932224plc.121.1660307858816; Fri, 12 Aug 2022 05:37:38 -0700 (PDT) In-Reply-To: <838rnws5c7.fsf@gnu.org> Received-SPF: pass client-ip=2607:f8b0:4864:20::1030; envelope-from=owinebar@gmail.com; helo=mail-pj1-x1030.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:293382 Archived-At: CC'ing Yuan Fu on Po Lu's recommendation earlier in the thread. On Wed, Aug 10, 2022 at 7:31 AM Eli Zaretskii wrote: > > > From: Lynn Winebarger > > Date: Wed, 10 Aug 2022 06:05:56 -0400 > > Cc: Po Lu , Alan Mackenzie , emacs-devel , > > Stefan Monnier > > > > It is simply too slow to be a modern solution for these features. > > > > Can you (or anyone on the list) provide a more detailed analysis? Is the slowness inherent in the algorithm > > design, the implementation method (eg table driven parsing designed before the availability of the native > > compiler), the basic synchronous nature of ELisp, the impact on garbage collection, etc? > > I don't have this information. Maybe someone else does. But in > general, it is a very small wonder that a parser written in optimized > C is much faster than anything written in Emacs Lisp, given that Lisp > is an interpreted language that has no special support for writing > parsers. That can be cured over time, now that the bulk of the core of emacs uses lexical scoping. With proper tail recursion, ELisp should be able to produce lexers and parsers roughly as efficient as C code, if not more efficient (depending on if you allow use of "computed goto" in the C code for the lexers and parsers). That does require changes to the byte code VM, but it's doable. > > > If the analyzer were run in a second emacs process using mmaped files to share buffers being analyzed, > > then communicating the results either via LSP or some other channel, would that make it usable? > > I doubt that. In particular, LSP-style communications are a cause of > slower operation, not faster operation. Various LSP-based packages > tolerate that because the server can do stuff clients cannot easily do > without investing a lot of language-specific efforts and expertise. That's more along the lines of what I expected (and Tassilo's response) - the overhead of creating and maintaining these language analyses in Emacs. But for a DSL, I'd personally prefer to be able to put something together "quickly" in emacs to get a working IDE. > > I've definitely noticed more pausing with Semantic turned on, but it's not unusable so far (but I'm also not > > looking at any C++ source, just ELisp and C, maybe some shell scripts, info files and Markdown). > > I didn't say Semantic is unusable. It certainly is usable. The pausing was in fact due to a different library - tabbar-ruler - that had for some reason made frequently refreshing the tab list call eval on a thunk instead of just calling the thunk, generating huge amounts of garbage from "eval". Since I corrected that, I haven't noticed much pausing. A better fix would make it stop refreshing tabs that aren't even displayed when Semantic takes over the header line, but that would require more effort. Lynn