Re: cc-mode fontification feels random

[Eli Zaretskii]

> From: Philipp <p.stephani2@gmail.com>
> Date: Fri, 4 Jun 2021 12:59:45 +0200
> Cc: João Távora <joaotavora@gmail.com>,
>  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.