[VM] debugging why emacs / vm becomes non-responsive

[Kyle Farrell]

I'm noticing emacs become non-responsive and take 100% of cpu
frequently on my Windows machine for about 15-20 seconds. This may
happen 2-3 times in 5 minutes, making the overall experience unusable.

I have two instances of emacs running, one for VM and another doing
other tasks (org-mode mainly). I only see the non-responsiveness in
the VM instance (which is why I'm starting here). When emacs becomes
non-responsive, I sometimes see a garbage collection messages. The
non-responsiveness does not seem tied to any particular action.

I'm using VM version 8.1.93a on GNU Emacs 23.3.1 (also verified with
23.1) on Windows Vista. The emacs process is at roughly 50 megs,
which should not tax the system.

What would be next steps in debugging this? I'm trying to debug why
this is happening and am looking for suggestions. While I'm not
convinced it's in VM, it only happens in the emacs process that I'm
using for VM.

thanks,
Kyle

[Uday Reddy]

Post by Kyle Farrell
I have two instances of emacs running, one for VM and another doing
other tasks (org-mode mainly). I only see the non-responsiveness in
the VM instance (which is why I'm starting here). When emacs becomes
non-responsive, I sometimes see a garbage collection messages. The
non-responsiveness does not seem tied to any particular action.

Garbage collection and auto-save are two Emacs features that affect VM. How
long these things take depends on the quality of your hardware. You can try
reducing the size of the mail folders, e.g., by archiving old mail, or
switching to an IMAP server and keep messages externally. You can also try
tweaking the auto-save settings. Here is what I use:

(setq auto-save-timeout 300)
(setq auto-save-interval 1000) ; up from the default of 300

Post by Kyle Farrell
I'm using VM version 8.1.93a on GNU Emacs 23.3.1 (also verified with
23.1) on Windows Vista. The emacs process is at roughly 50 megs,
which should not tax the system.

You might also switch to VM 8.2.0a, which would have some bug fixes that
might affect performance.

Cheers,
Uday

[Kyle Farrell]

Thanks Uday. I was likely running into the auto-save-interval. I've
up'd that value and which helps considerably. I know that's not
necessarily a good thing but it makes the session usable.

Can auto-save-interval be buffer specific? If I could limit it to the
INBOX that would be minimize risk to other buffers. Meanwhile I'll
try to reduce my INBOX from 1800 overly large html messages (thanks
Outlook users!) to something reasonable or consider reading via IMAP.

Post by Uday Reddy

Post by Kyle Farrell
I have two instances of emacs running, one for VM and another doing
other tasks (org-mode mainly). I only see the non-responsiveness in
the VM instance (which is why I'm starting here). When emacs becomes
non-responsive, I sometimes see a garbage collection messages. The
non-responsiveness does not seem tied to any particular action.

Garbage collection and auto-save are two Emacs features that affect VM. How
long these things take depends on the quality of your hardware. You can try
reducing the size of the mail folders, e.g., by archiving old mail, or
switching to an IMAP server and keep messages externally. You can also try
(setq auto-save-timeout 300)
(setq auto-save-interval 1000) ; up from the default of 300

Post by Kyle Farrell
I'm using VM version 8.1.93a on GNU Emacs 23.3.1 (also verified with
23.1) on Windows Vista. The emacs process is at roughly 50 megs,
which should not tax the system.

You might also switch to VM 8.2.0a, which would have some bug fixes that
might affect performance.
Cheers,
Uday

[Uday Reddy]

Post by Kyle Farrell
Can auto-save-interval be buffer specific? If I could limit it to the
INBOX that would be minimize risk to other buffers. Meanwhile I'll
try to reduce my INBOX from 1800 overly large html messages (thanks
Outlook users!) to something reasonable or consider reading via IMAP.

You can try putting

(make-variable-buffer-local 'auto-save-interval)

in your .emacs file and see if that does the trick.

The growing size of the mail folders is precisely why I have implemented
external messages (formerly called "headers-only" messages). They are
available for IMAP right now. In due course, they will be available for
local folders as well via the maildir format.

Cheers,
Uday