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.bugs Subject: bug#59738: c-ts-mode is slow with large buffers. Date: Sun, 11 Dec 2022 08:45:21 +0200 Message-ID: <83r0x6v3pa.fsf@gnu.org> References: <87E351E0-2EE2-434A-9609-86506D2F263D@gmail.com> <83edtb3z6t.fsf@gnu.org> <3A956C88-F81D-4DED-B020-178291D405D9@gmail.com> <83fsdp1vke.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8293"; mail-complaints-to="usenet@ciao.gmane.io" Cc: casouri@gmail.com, 59738@debbugs.gnu.org To: Alan Mackenzie Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Dec 11 07:46:23 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1p4G6Q-0001xZ-04 for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 11 Dec 2022 07:46:22 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p4G69-0007qQ-6w; Sun, 11 Dec 2022 01:46:05 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p4G67-0007qC-CN for bug-gnu-emacs@gnu.org; Sun, 11 Dec 2022 01:46:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1p4G67-00020d-0M for bug-gnu-emacs@gnu.org; Sun, 11 Dec 2022 01:46:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1p4G66-0005cw-Jq for bug-gnu-emacs@gnu.org; Sun, 11 Dec 2022 01:46:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 11 Dec 2022 06:46:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 59738 X-GNU-PR-Package: emacs Original-Received: via spool by 59738-submit@debbugs.gnu.org id=B59738.167074115721622 (code B ref 59738); Sun, 11 Dec 2022 06:46:02 +0000 Original-Received: (at 59738) by debbugs.gnu.org; 11 Dec 2022 06:45:57 +0000 Original-Received: from localhost ([127.0.0.1]:46123 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p4G60-0005cg-K7 for submit@debbugs.gnu.org; Sun, 11 Dec 2022 01:45:56 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:58794) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p4G5x-0005cY-J1 for 59738@debbugs.gnu.org; Sun, 11 Dec 2022 01:45:55 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p4G5p-0001yE-Ve; Sun, 11 Dec 2022 01:45:47 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=jVSmzOTqTC5CsnnTKkdJdh+BEvCCgW2ZtM7BlhCmc2Y=; b=jejrzdqDl/iHVxNlTE1p 1j7fEzvw3Ri9K22pZaCVqsDqaHsydq8cO+9STiTRLyKxMGBpq7qGLlCS2H9uCGK+gS9Vzz72iQyls 9nxSxIiFvIZMQUaJi90+cOEQ0PeIUxVsDC8LhVO3/+0ibm+hPSjFTieB5EvsVBjU1yLS20l/2GkzM saT741bRR8CxdsrMPiyuJQWdLhWBxysyFKg0QsjA8aA/1Vh5cuOb8grKdX5lC/eK2pHSeu5UZPxVU gFO62scQQCHv9tTLDxGIFj2uxon9FuC9QGlHz00+USOzRmbv6Z9lV5wNA/exHY1Rj9n0zv5yGTK31 QLIZzzq/VUf0jg==; Original-Received: from [87.69.77.57] (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 1p4G5T-00044b-Iq; Sun, 11 Dec 2022 01:45:37 -0500 In-Reply-To: (message from Alan Mackenzie on Sat, 10 Dec 2022 21:34:20 +0000) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:250575 Archived-At: > Date: Sat, 10 Dec 2022 21:34:20 +0000 > Cc: Yuan Fu , 59738@debbugs.gnu.org > From: Alan Mackenzie > > > Thanks, now c-ts-mode is twice as fast as c-mode with that file. > > > Great job! > > The bug which was causing it to be very slow is fixed, so I agree, > excellent job! > > But I've measured it as being 62% faster (not twice as fast) as CC Mode. > A "normal" C file (xdisp.c) is around 160% faster, i.e. a little over 2½ > times as fast. You do all your measurements in an optimized build of Emacs. I did mine in an unoptimized build, something that I need to use all the time, even though my production sessions run optimized builds. In an unoptimized build CC Mode is extremely slow. For example, just visiting dce_12_0_sh_mask.h file takes a whopping 67 sec, and M-> immediately after the file is displayed takes another 25 sec. With c-ts-mode, these numbers are, respectively, 1.8 sec and 2 sec. IOW, scrolling through the whole humongous file measures some aspect of the redisplay (actually, JIT font-lock) performance, but that is not all that matters when one has to edit a file; the above two situations are also important use cases. However, talking only about speed is looking at this from an incorrect aspect, see below. > But given how slow CC Mode was held to be, is a factor 2.6 speed-up > really all that we were expecting from c-ts-mode? This is the sort of > speed-up one would get by replacing a 5 year old machine with a new one, > or using an optimised build in place of a debug build. Speed is not the main reason why we want to have font-lock and indentation based on a parser library. The main reason is _correctness_ and _accuracy_. A regexp-based fontification and indentation engines will never be able to match parser-based engines, because they doesn't really understand the source code. Even when aided by syntax-ppss, they only catch some part of the syntax, and none of the semantics. The hope is that using a parser will allow us to provide much more accurate implementations. Whether and how much this hope will materialize is yet to be seen, but looking just at the speedup is definitely not TRT for assessing the success of this development in Emacs.