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 14:18:36 +0300 Message-ID: <83pmx1vpwz.fsf@gnu.org> References: <831r9iw473.fsf@gnu.org> <87h7ieyma7.fsf@gmail.com> <83wnr9vrpj.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="3358"; mail-complaints-to="usenet@ciao.gmane.io" Cc: ubolonton@gmail.com, dancol@dancol.org, theo@thornhill.no, joaotavora@gmail.com, emacs-devel@gnu.org To: Philipp Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jun 04 13:19:20 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 1lp7rD-0000kq-0F for ged-emacs-devel@m.gmane-mx.org; Fri, 04 Jun 2021 13:19:19 +0200 Original-Received: from localhost ([::1]:48498 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lp7rC-0005AB-0I for ged-emacs-devel@m.gmane-mx.org; Fri, 04 Jun 2021 07:19:18 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35140) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lp7qj-0004Vw-Ps for emacs-devel@gnu.org; Fri, 04 Jun 2021 07:18:49 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:52370) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lp7qg-0008Us-VG; Fri, 04 Jun 2021 07:18:46 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3994 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 1lp7qg-0002O6-Hu; Fri, 04 Jun 2021 07:18:46 -0400 In-Reply-To: (message from Philipp on Fri, 4 Jun 2021 12:59:45 +0200) 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:270381 Archived-At: > From: Philipp > Date: Fri, 4 Jun 2021 12:59:45 +0200 > Cc: João Távora , > ubolonton@gmail.com, > dancol@dancol.org, > theo@thornhill.no, > emacs-devel@gnu.org > > > The communication of buffer contents to these agents/servers is indeed > > one aspect of the existing packages (those I had time to look at) that > > I personally am unhappy about. Sending the whole buffer or its large > > chunks down the wire as buffer-substring (which requires encoding to > > be correct) is non-scalable, especially if it also requires conversion > > to JSON. > > How bad is is actually; are there good numbers on this? It doesn't matter to me; we cannot go that way in core. And there's no reason, really. > A while ago, I tested this hypothesis by transferring the `buffer-string' of xdisp.c to a Go module. This goes through a full UTF-8 encoding and makes three copies (first, to create the string object; then, to copy it to the module interface; lastly, to make a Go string out of it), and it still only took a few milliseconds. > Modern CPUs are very good at copying memory, so maybe we're optimizing the wrong thing here. We definitely should have good benchmarks and profiling data before deciding what to optimize. First, for LSP this is not a memory copy. Second, buffer-string (or buffer-substring) conses a Lisp string, which increases memory pressure and GC. Imagine doing this for many buffers. E.g., I have jit-lock-stealth enabled, so Emacs fontifies buffers in the background whenever it is idle. And third, why settle for an inferior solution that scales badly, when a superior one is just around the corner? I understand why we would want to compromise if there were no alternatives, but why compromise up front when a better alternative exists? It makes no sense to me.