Stress-testing vundo

[jdtsmith]

This provides a stress test of the undo/vundo system, creating and benchmarking (potentially) very large and wide undo trees. By default it creates a random tree of edits (based on lorem-ipsum sentences) in the buffer *vundo-stress-test*, with each undo boundary encapsulating the addition/removal of a single sentence (of varying length). It then benchmarks launching vundo in this buffer, and (optionally) navigating to the vundo tree root.

Navigating near the tree root of large trees often leads to assertion errors, which may arise from the "tail trimming" process. See vundo-stress-test for information on interactive use.

Note that jit-lock-mode is disabled in the vundo buffer to prevent unspecified jit-locking errors; it's possible this should be included in vundo-mode itself.

[jdtsmith]

Example output with the defaults (on a fairly slow machine):

> Undo stress test complete: 3000 sentences inserted, 500 undo chains of max length 14
undo-limits: 1000000 strong: 2000000 outer: 24000000
Buffer has 3477 lines, 21340 words, and 152335 characters.
buffer-undo-list: length   13333,   1128233 bytes
>> Launching vundo:
Elapsed time: 0.856160s (0.244196s in 1 GCs)
>> Navigating to tree root:
Elapsed time: 1.784064s
buffer-undo-list: length   51631,   2316571 bytes

[ideasman42]

Note: with these kinds of tests in general, I find it's most helpful if randomness supports using a seed, so in the event a bug is triggered - it's possible to redo the same error again or tell a developer the seed used so they can investigate it. (a nil seed for can use the current time for e.g. but supporting a fixed seed is useful for development). It looks like this is possible, see: https://www.gnu.org/software/emacs/manual/html_node/elisp/Random-Numbers.html

[jdtsmith]

Looks like this is easily arranged by initializing with a seed beforehand:

(progn 
  (random "SEED123") 
  (vundo-stress-test 10 3 2 nil))

[casouri]

Merged, thanks!