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: cc-mode fontification feels random Date: Fri, 04 Jun 2021 17:11:53 +0300 Message-ID: <83y2bplnx2.fsf@gnu.org> References: <831r9iw473.fsf@gnu.org> <87h7ieyma7.fsf@gmail.com> <83wnr9vrpj.fsf@gnu.org> <83o8clvpq4.fsf@gnu.org> <878s3pzqsb.fsf@gmail.com> 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="29106"; mail-complaints-to="usenet@ciao.gmane.io" Cc: p.stephani2@gmail.com, dancol@dancol.org, theo@thornhill.no, ubolonton@gmail.com, emacs-devel@gnu.org To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jun 04 16:12:54 2021 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 1lpAZB-0007P0-GT for ged-emacs-devel@m.gmane-mx.org; Fri, 04 Jun 2021 16:12:53 +0200 Original-Received: from localhost ([::1]:50736 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lpAZ9-0001rO-ND for ged-emacs-devel@m.gmane-mx.org; Fri, 04 Jun 2021 10:12:51 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45568) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lpAYP-0001AN-8V for emacs-devel@gnu.org; Fri, 04 Jun 2021 10:12:05 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:36376) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lpAYN-0005gv-A1; Fri, 04 Jun 2021 10:12:03 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2910 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 1lpAYM-0002Fh-Sr; Fri, 04 Jun 2021 10:12:03 -0400 In-Reply-To: <878s3pzqsb.fsf@gmail.com> (message from =?utf-8?B?Sm/Do28g?= =?utf-8?B?VMOhdm9yYQ==?= on Fri, 04 Jun 2021 14:46:12 +0100) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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:270387 Archived-At: > From: João Távora > Cc: p.stephani2@gmail.com, ubolonton@gmail.com, dancol@dancol.org, > theo@thornhill.no, emacs-devel@gnu.org > Date: Fri, 04 Jun 2021 14:46:12 +0100 > > Eli Zaretskii writes: > > >> a big and complex buffer would give rise to one of these big and complex > >> JSON messages. > > Ask Dmitry about performance problems with native JSON support, and > > the effort we invested (a year ago?) into optimizing UTF-8 encoding of > > strings, to squeeze every last percent of performance. > > As I remember, the biggest bottleneck was parsing and allocating Lisp > objects. But that's exactly the problem: the packages I've seen try to solve this on the Lisp level, and that just has got to involve consing of Lisp objects, so there's no way around that problem with this approach. By contrast, fast access to buffer text is on the C level, similar to what we do with regexp search, and doesn't require any Lisp objects as intermediates. The other problem with the integration of this packages into Emacs (again, those few packages that I took a good enough look at) is that they don't plug themselves into the JIT lock mechanism triggered by redisplay, and instead use all kinds of hooks to put text properties on buffer text (and turn off font-lock for that to work). That's another aspect of IMO poor integration into the Emacs core, probably again because of the desire to stay away of C and the innards of the display engine. > Commonly, it means parsing a big JSON message even if you're > only interested in a fraction of it (and this happens in LSP when > e.g. some servers decide to serve up huge buckets of diagnostics > unrelated to the current file being edited, for instance). The json.c > parser is faster, but ultimately borks here, too. > > My idea at the time was to develop a technique to only parse the bits of > JSON we're interested in, which dramatically improved performance. I think this is a separate issue. I guess if the percentage of "garbage" is large, then this will indeed be a win, but it must come with some overhead (to figure out what is "garbage"), so it isn't going to produce significant speedup with milder amounts of "garbage". And this is only relevant if the protocol is based on JSON. > And again, for fontification, this point is probably moot if we're going > to integrate tree-sitter directly with direct access to the buffer > (which just makes sense). Only if someone does the job.