slow response on first buffer edit

slow response on first buffer edit

[Conrad Lloyd-Knight]

Hi,

I didn't see this in the FAQ, or in a quick perusal of the archives
for this list...

The problem I'm having is on one particular machine where I have emacs
21.3.1 installed. I have the same version installed on 3 machines and
this is the only one showing this. 

The first edit of a buffer causes a high CPU load for about 10s before
any changes show up in the window. This occurs when emacs is started
with:
   emacs filename
but not when started with just:
   emacs
(in other words, the effect doesn't show up when editing the scratch
buffer). It occurs whether filename is an existing file or a new one.

I can move around the buffer using the cursor keys, etc. but the
moment I make a change to what is displayed (kill a line, type a
character...) the system appears to hang for 10s before the change is
displayed. 

I have also noticed that this hangup occurs before a symbolic link is
created, by the name of .#filename, pointing to a non-existant file
called user@full.hostname.PID:somelongnumber. I do not believe the
delay is caused by creating this link, as I can manually create a
similarly named one without any delay, but this might give someone an
idea at what point it occurs.

Another data point: I can open a second file in another buffer and
edit this afterwards without another delay.

This issue has me stumped, so if anyone else has seen this, I'd
appreciate any insight. Or if anyone has any suggestions on how to
diagnose this further, please let me know! :)

Thanks,
-C.

Re: slow response on first buffer edit

[Conrad Lloyd-Knight]

Answering my own question here, just in case anyone else runs into
this...

> I have also noticed that this hangup occurs before a symbolic link is
> created, by the name of .#filename, pointing to a non-existant file
> called user@host.name.PID:somelongnumber. 

Running emacs with a debugger shows that during this hang time it's
accessing /var/log/wtmp. A look through the code for filelock.c
reveals that the somelongnumber is actually the time of the last
reboot (not sure why...), which emacs is trying to pull from the wtmp
file. Only in my case, the machine in question had a wtmp file over
90MB in size, which caused the delay. Flushing wtmp solved the
problem.

-C.