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.