bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#122: 23.0.60; Slowdown in directory scanning over time.


From: Len Trigg
Subject: bug#122: 23.0.60; Slowdown in directory scanning over time.
Date: Mon, 15 Sep 2008 09:24:22 +1200
User-agent: Wanderlust/2.15.6 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (Gojō) APEL/10.7 Emacs/23.0.60 (i686-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO)

Len Trigg wrote:
> (tramp-flush-file-function erc-kill-buffer-function 
> browse-url-delete-temp-file jde-db-nullify-breakpoint-markers 
> vc-kill-buffer-hook)
> 
> I can try restarting my emacs without using some of those features for
> the next few days.

I think I have some more information on where those extra
code-conversion-work buffers are coming from.  I have a crontab
scheduled script that regularly downloads ics calendar files from
various locations and uses icalendar.el to convert them to diary
format (which are then #included by my main diary file).  This
conversion uses a separate "emacs -batch" process in order to not
interfere with my main emacs, and then finally calls emacsclient at
the end to tell my main emacs to update it's current diary display, if
present.

If I disable this script entirely, the code-conversion-work buffers
don't accumulate.

If I disable the final call to emacsclient, the code-conversion-work
buffers do still accumulate (eliminating emacsclient as the culprit).

If I disable global-auto-revert mode in my main emacs, the
code-conversion-work buffers don't accumulate.

So it seems to be related to the modified diary files being
auto-reverted.  I have not managed to work out any more details than
that.


Regardless of why they are leaking, it seems to me that Richards
suggestion of eliminating the use of multiple code-conversion buffers
at all is probably the way to go.


Cheers,
Len.







reply via email to

[Prev in Thread] Current Thread [Next in Thread]