Emacs 23 slow -- especially on Cygwin

[Makarius]

My general impression when using PG 3.7.1 or 4.0 with Emacs 23 is that is a bit slow. On Linux this is somehow bearable, but on Cygwin 1.7 it renders PG almost unusable. Since there is no Emacs 22 on Cygwin 1.7 or 1.5 (which are the current versions), the only alternative for now seems to be XEmacs 21.4.x. This means we need to fall back on old PG 3.7.1 for this platform!?!?

[David Aspinall]

This is a nuisance, but is the problem actually due to PG code? Can you be more explicit than just giving a general impression, e.g., do some measurements on explicit test files?

If it is a general problem with the Emacs port then it should be reported to the Emacs bugs list (for official ports) or elsewhere (unofficial).

[Makarius]

Hard to tell. Here is another instance ​http://osdir.com/ml/debian-bugs-dist/2009-11/msg00210.html

On Cygwin the effect is as bad as this: every 5 seconds, PG/Emacs "hangs" for 1 second, but this pattern is not very reliable. It is not due to garbage collection.

The only (partially) usable Emacs on Cygwin 1.5 or 1.7 seems to be XEmacs 21.4.x, so we are forced to use PG 3.7.1 here. (Which does not mean that PG 4.0 really works on the other platforms, so my tendency is to use PG 3.7.1.1 uniformly for now.)

[Makarius]

See also ​http://groups.google.com/group/linux.debian.bugs.dist/browse_thread/thread/45fcba2136f05fcc/ffdc1448b1b0873f?lnk=raot

[David Aspinall]

OK. Unfortunately that other bug report has no further information either.

You could try adjusting `process-adapative-read-buffering' which is a new low-level variable affecting sub-process interaction. It defaults on Linux to t, I don't know about the other platforms. Setting it to another non-nil value behaves badly with Isabelle, as the output chunks arrive in different sizes.

Please let me know if this improves things. Otherwise we'll have to close this here as a non-PG issue, I don't have enough bandwidth to track upstream Emacs problems.

Impressed by the dedication to Windows/Cygwin? now...

[Makarius]

This is Windows XP/SP3 running on Virtual Box.

Same problem, this time GNU Emacs 23.2.1, Cygwin 1.7.7, Isabelle_14-Jan-2011 from http://www4.in.tum.de/~wenzelm/test/Isabelle_14-Jan-2011/download.html --- the bundle already contains ProofGeneral-4.1pre110112.

My impression is that the shell process communication is slow, similar to the Mac OS X problem we've had before.

On the same machine isabelle jedit runs reasonably well, despite limited hardware ressources.

[Makarius]

Here is another configuration: Virtualbox 4.0 on Mac OS X Snow Leopard, virtual machine with 4 GB RAM, 4 CPU cores, running Windows 7, Cygwin 1.7.7 with GNU Emacs 23.2.1.

This makes the Proof General 4.1 experience a bit more smooth, although not really fast.

[David Aspinall]

Instead of impressions: you can try "make profile.isar" in each case and note the differences in timings.

Also, interactively, please try with "Fast Process Buffer" option which was the work-around I added for Mac OS X. If that improves things for Cygwin it can be made default there too.

Unfortunately I can't personally undertake to test or support this environment but I'm happy to accept patches that improve matters.

I think to take this further and report an Emacs bug useful for Emacs developers we probably need some simpler example that exhibits the problem in an Emacs shell. Is outputting data (like the Unix command "yes") enough? Can you try a loop in bash or something similar that produces a count output on the terminal and demonstrate the slow down? Or do we need input as well?

[Makarius]

I have basically given up on the combination of PG 4.1 + GNU Emacs 23 on Cygwin, and switched back to ancient PG 3.7.1.1 + XEmacs.

[David Aspinall]

OK. I have tried to change the default for `proof-fast-process-buffer' on this platform anyway, and hope someone will be able to try it out and report if it becomes usable.

Closing this ticket meanwhile as there is an almost complete lack of useful information to investigate the problem and it's liable to be in low-level Emacs code.