Re: Mitigating the long-lines penalty in vundo

[Eli Zaretskii]

> From: JD Smith <jdtsmith@gmail.com>
> Date: Sun, 17 Dec 2023 14:26:23 -0500
> Cc: emacs-devel@gnu.org,
>  casouri@gmail.com
> 
> > Lisp programs are not supposed to need frequent column calculations,
> > certainly not several times on the same line.
> 
> Maybe then it’s worth a word of warning in the current-column docs mentioning 
> this in the context of faces, unicode, and long-line performance?

I'm not sure.  It was never a problem until now.  Warning against very
rare issues could have negative effects of its own.

> >> * current-column is quite slow counting unicode characters: about 21x 
> >> slower than the ascii
> >> equivalents.  Perhaps this is because unicode chars can have non-standard 
> >> widths, so emacs
> >> needs to do some additional checks?
> > 
> > No.  I can understand why non-ASCII characters are somewhat slower,
> > since each one of them is several bytes, not just one, and we convert
> > the multibyte representation into a codepoint on the fly.  But 21-fold
> > slowdown sounds excessive.
> 
> Results may vary by system/font I suppose; perhaps others could run the 
> simple test in my last message (no non-default packages required) and report 
> back what slowdown factor they get.

current-column does not depend on fonts and knows nothing about fonts.
The canonical width of every character is stored in a char-table that
is indexed only by the character's codepoint, and is independent of
any real font metrics.

> > There's one more factor to consider here: current-column always starts
> > from the beginning of the line.  If vundo needs to call current-column
> > many times on the same line, it loses because it each time starts from
> > BOL, in effect throwing away the results of the previous calculation.
> > This wastes CPU cycles.  It might be better to use sum char-width
> > values of individual characters instead.
> 
> Definitely; it’s clear how repetitive/wasteful this is.  I wonder, similar to 
> line-numbers, could we cache current-column at various points along a line 
> and apply a delta?  I.e. for computing line numbers differentially we have
> 
> (count-lines start end) 
> 
> which linum and others use to good effect.  Is there a similar
> 
> (count-columns start end)?  

This is impossible in general (think TABs).  What we can do is provide
something like

  (count-columns startpos startcol endpos)

IOW, we need to tell the function what is the column at STARTPOS.  And
then there will be problems if STARTPOS is "covered" by an overlay or
a display property...