Closed fdupress closed 5 months ago
Hold on to your hats: the issue does not occur if emacs is running in TUI mode. (I was trying to record the behaviour.)
I'm looking into the emacs angle. @alleystoughton can you please confirm your emacs version, and that you're on the latest PG? (I still don't understand why switching ocaml compiler would make a difference, but we'll figure that out later.)
I'm running GNU Emacs 29.1 from https://emacsformacosx.com
And yes, on latest PG from opam.
Thanks. Sorry for the red herring: the issue does pop up regardless of emacs interface (phew! that would have been a real puzzler).
Recording here, after a few tries so it starts already quite slow.
The proof is irrelevant. The left-most buffer is the *easycrypt*
buffer, and it clearly shows that the message is slow to print, but even slower to end. Most of the slow down is due to increasingly long delays in finishing the message once all printing is done.
Failures fail quickly, so it looks like something in goal printing whose complexity grows with the number of calls that have been made to the goal printing function.
This has nothing to do with ProofGeneral. I just noticed that having a tight-loop with a lot of printing (cumulatively) slow-down things too.
Seems it might be possible to send the OCaml developers a self-contained program illustrating the bug?
Self-contained, but far from being minimal. I don't even understand what is, as of today, the best way to profile an OCaml program.
See #517
Is this issue been fixed by #517?
Yes.
Closing then.
This is reviving the OG #390, which I had prematurely conflated with the general memory consumption issues related to OCaml 5.0 (now fixed with OCaml 5.1).
In particular, the following still occurs in interactive usage.
To reproduce:
Expected behaviour: The proof step gets undone and redone with no perceptible performance change.
Observed behaviour: The time it takes to both undo and redo will increase rapidly. Memory used by EC goes up with each interaction (by a few 10s of MB!), but not sufficiently to justify the massive slow down.
Changing the proof step to be a trivial failure halves the wait time, which seems to indicate that something is going on both in parsing and formatting messages for emacs. This may also affect print-heavy non-interactive behaviour, but I have not tested.
Performing step 0 with an OCaml 4.14.2 switch yields the expected behaviour.
Thanks to @alleystoughton for reporting and early investigation. This was confirmed on a Mac M1 (by Alley) and Linux (by me).