From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: desktop.el: autosave? Date: Thu, 06 Dec 2007 21:47:02 -0500 Message-ID: References: <8763zjfe0v.fsf@jurta.org> <87mysridxt.fsf@jurta.org> <20071206153806.GA20731@www.trapp.net> <87d4tjbh0g.fsf@jurta.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1196995641 12085 80.91.229.12 (7 Dec 2007 02:47:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 7 Dec 2007 02:47:21 +0000 (UTC) Cc: tomas@tuxteam.de, emacs-devel@gnu.org, rms@gnu.org, Reuben Thomas To: Juri Linkov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 07 03:47:30 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1J0TFS-0008KZ-3O for ged-emacs-devel@m.gmane.org; Fri, 07 Dec 2007 03:47:30 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J0TFB-0003pO-84 for ged-emacs-devel@m.gmane.org; Thu, 06 Dec 2007 21:47:13 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1J0TF7-0003pJ-OT for emacs-devel@gnu.org; Thu, 06 Dec 2007 21:47:09 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1J0TF6-0003p7-7p for emacs-devel@gnu.org; Thu, 06 Dec 2007 21:47:09 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J0TF6-0003p4-59 for emacs-devel@gnu.org; Thu, 06 Dec 2007 21:47:08 -0500 Original-Received: from tomts40.bellnexxia.net ([209.226.175.97] helo=tomts40-srv.bellnexxia.net) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1J0TF2-0000du-C4; Thu, 06 Dec 2007 21:47:04 -0500 Original-Received: from toip7.srvr.bell.ca ([209.226.175.124]) by tomts40-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with ESMTP id <20071207024703.TPNZ1617.tomts40-srv.bellnexxia.net@toip7.srvr.bell.ca>; Thu, 6 Dec 2007 21:47:03 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAHtCWEdKDNGS/2dsb2JhbACBWg Original-Received: from bas1-montreal42-1242354066.dsl.bell.ca (HELO pastel.home) ([74.12.209.146]) by toip7.srvr.bell.ca with ESMTP; 06 Dec 2007 21:47:53 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id A58BF7FAC; Thu, 6 Dec 2007 21:47:02 -0500 (EST) In-Reply-To: <87d4tjbh0g.fsf@jurta.org> (Juri Linkov's message of "Fri, 07 Dec 2007 01:28:23 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.50 (gnu/linux) X-detected-kernel: by monty-python.gnu.org: Solaris 8 (1) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:84822 Archived-At: > Saving a buffer's file is fast operation comparing to saving the desktop > that takes more time because it is a cpu-intensive task that collects > information from all buffers and some possibly long lists and writes > to the usually large desktop file. The default timeout for auto-save > is 30 sec which is ok for auto-saving normal files, but I don't see a > need to waste resources to save the desktop so often. I have a hard time believing that it's so "CPU intensive". Collecting info about 100 buffers is a no brainer that should be done in a tiny fraction of a second even on a 10 year old CPU. As for "large desktop file", how large are we talking about? anything smaller than 100KB is not large nowadays. > I have no serious problems with short intervals, but some users may have > for various reasons (low memory that causes reading from the swap space > when collecting data to save to the desktop file, slow disk access, etc.). When swapping, you might be better off using a short idle interval so as to reduce the risk of the pages having been swapped out while "idling" (i.e. while some other process ran). > So users may want to increase the timeout for the idle timer. But the main > problem with idle timers is that with long intervals they may never run. Worse yet: long interval means it will be run right when the machine is idle, i.e. when the disk was spun down. Better run it when the machine is still "active" so there's a better chance that the drive is already spinning. On top of that, writing to a file does not necessarily imply spinning up the disk, because the actual write might be delayed by the OS to save power. Stefan