From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Why tree-sitter instead of Semantic? (was Re: CC Mode with font-lock-maximum-decoration 2) Date: Wed, 10 Aug 2022 14:31:04 +0300 Message-ID: <838rnws5c7.fsf@gnu.org> 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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="20756"; mail-complaints-to="usenet@ciao.gmane.io" Cc: luangruo@yahoo.com, acm@muc.de, emacs-devel@gnu.org, monnier@iro.umontreal.ca To: Lynn Winebarger Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Aug 10 13:32:44 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 1oLjx5-00059c-Rk for ged-emacs-devel@m.gmane-mx.org; Wed, 10 Aug 2022 13:32:44 +0200 Original-Received: from localhost ([::1]:33554 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oLjx4-00011r-Bf for ged-emacs-devel@m.gmane-mx.org; Wed, 10 Aug 2022 07:32:42 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54474) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oLjvl-0000Gs-SG for emacs-devel@gnu.org; Wed, 10 Aug 2022 07:31:21 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:58748) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oLjvd-0007yn-Or; Wed, 10 Aug 2022 07:31:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=YXzyCLqD0uH3K4YprQelIzqICf2f9S0AIAph5VJR0Uk=; b=sX/C9QWptJAo QAiRkOazi5DtnizL5CyTvUxpJtmmnkeWT5IyfXkvNtgNSeB/QSydbug/wOvmTQnKMeAJfwPm2PhmE LzkvwP6PlDbMZMfkPTHkBIX11Pe6945fQE0YSrUk5IrX3IV06UUPZRa7Hxq4BaqticX+UnUXVZMap ZyH3n/Lj2Lw8NJqTvHz2g8URKJumP0cAbGriUyMSfbR/sRCsHaqDY5qZkqyi1nwQ3dol+noO/s4tZ GfjzBJcTa4gNBhRAPvrbWyTDSKefBZF4JIPwc7eXmHyrG7tl2jW+cSyZNcSKL2DIz5l3KhGh0dFQ/ f1I9EmbXZLKcBzlUdBiH4Q==; Original-Received: from [87.69.77.57] (port=3009 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oLjvd-0006vg-0p; Wed, 10 Aug 2022 07:31:13 -0400 In-Reply-To: (message from Lynn Winebarger on Wed, 10 Aug 2022 06:05:56 -0400) 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:293349 Archived-At: > 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. > 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. > 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.