Re: Mitigating the long-lines penalty in vundo

[Eli Zaretskii]

> From: JD Smith <jdtsmith@gmail.com>
> Date: Sat, 16 Dec 2023 13:54:40 -0500
> Cc: emacs-devel@gnu.org,
>  casouri@gmail.com
> 
> >> 
> > 
> > (I don't understand what was supposed to be shown in my MUA at this
> > place; what I see is as single character U+FFFC.)
> 
> Apologies; you’d think inline images could survive passage in 2023!   These 
> two images were included in the OP:
> 
> https://private-user-images.githubusercontent.com/93749/289367869-b0d8ab4f-c231-4964-85ba-d9ecc20363b0.png
> https://private-user-images.githubusercontent.com/93749/290972630-54f81ca6-4e4e-4943-a5a1-d8a949bd3c33.png

I cannot view these images: my browser says there are errors, and if I
try downloading them with wget, I get 404...

> > Maybe the stuff you display uses some characters that make
> > redisplay slower for reasons other than line-length?  What kind of
> > characters are used for showing these "undo-trees"?
> 
> Nothing fancy, just characters from either one of these two sets (with faces 
> applied):
> 
> (defconst vundo-ascii-symbols
>   '((selected-node . ?x)
>     (node . ?o)
>     (horizontal-stem . ?-)
>     (vertical-stem . ?|)
>     (branch . ?|)
>     (last-branch . ?`)))
> 
> (defconst vundo-unicode-symbols
>   '((selected-node . ?●)
>     (node . ?○)
>     (horizontal-stem . ?─)
>     (vertical-stem . ?│)
>     (branch . ?├)
>     (last-branch . ?└)))
> 
> I just retried my test with the ascii-only symbols, and it resulted in a 
> modest 17% speedup, but still >20s at 32K columns.

Very strange.  Profiling should point out the culprit, especially if
you load the .el file (not .elc!) and then profile.

> To confirm, it’s your understanding that functions like all those mentioned 
> above (goto-char, looking at, delete-char, move-to-column, insert) should be 
> agnostic w.r.t. the length of lines, for buffers of the same total character 
> count?  

Yes.  Emacs editing commands are largely unaware of lines, unless Lisp
programs invoke functions that are sensitive to lines, like
end-of-line etc.  Buffer text is stored as a C string, it is not
subdivided into lines.  Only the display engine is sensitive to lines.

> > Bottom line: I don't think I understand what causes your problems.
> > The information presented is insufficient for even guessing the
> > possible reasons.  Please consider telling more.
> 
> I did include a link to the short draw function itself; not sure if you saw 
> that.  And I demonstrated clearly (IMO of course) that the performance 
> slowdown depends directly on the max column count of the displayed buffer.  
> As a small bit of constructive feedback, this take (“insufficient for even 
> guessing the possible reasons”) strikes me as uncharitable given this context.

You must understand that I don't have time to study non-trivial code
when such questions are posted.  I spent 8 hours today reviewing and
installing patches, merging the release branch to master, fixing bugs
people reported over the last days, etc.  So by "insufficient
information" I meant what was presented explicitly, both here and in
the discussion of the issue.  My best suggestion so far is to profile
the code; if you are certain you know which function is problematic,
profile that after loading the code as .el file, and show the
completely expanded profile.  The profiles you've shown until now
indicate that vundo--draw-tree is the hot spot, so loading it as a .el
file and running "M-x profiler-start" followed by "M-x profiler-report"
when it finishes should show the expensive parts.

Another idea is to increase the GC threshold, in case what slows this
down is the amount of garbage created by this code.