From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Luc Teirlinck Newsgroups: gmane.emacs.devel Subject: Re: PURESIZE increased (again) Date: Sat, 22 Apr 2006 20:59:51 -0500 (CDT) Message-ID: <200604230159.k3N1xpBu021881@jane.dms.auburn.edu> References: <87lku5u6tx.fsf@pacem.orebokech.com> <200604212310.k3LNA3Jp018780@jane.dms.auburn.edu> NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1145757647 7617 80.91.229.2 (23 Apr 2006 02:00:47 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 23 Apr 2006 02:00:47 +0000 (UTC) Cc: romain@orebokech.com, emacs-devel@gnu.org, Reiner.Steib@gmx.de, miles@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Apr 23 04:00:45 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1FXTu1-0008Kn-0W for ged-emacs-devel@m.gmane.org; Sun, 23 Apr 2006 04:00:45 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FXTu0-0000xd-LB for ged-emacs-devel@m.gmane.org; Sat, 22 Apr 2006 22:00:44 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FXTtp-0000xY-Ni for emacs-devel@gnu.org; Sat, 22 Apr 2006 22:00:33 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FXTto-0000xM-1c for emacs-devel@gnu.org; Sat, 22 Apr 2006 22:00:33 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FXTtn-0000xJ-RE for emacs-devel@gnu.org; Sat, 22 Apr 2006 22:00:31 -0400 Original-Received: from [131.204.53.104] (helo=manatee.dms.auburn.edu) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FXTvg-0006jY-Gn; Sat, 22 Apr 2006 22:02:28 -0400 Original-Received: from jane.dms.auburn.edu (jane.dms.auburn.edu [131.204.53.201]) by manatee.dms.auburn.edu (8.13.6/8.13.6) with ESMTP id k3N20S4c029049; Sat, 22 Apr 2006 21:00:28 -0500 (CDT) Original-Received: from jane.dms.auburn.edu (localhost [127.0.0.1]) by jane.dms.auburn.edu (8.13.4+Sun/8.13.3) with ESMTP id k3N1xpF8021884; Sat, 22 Apr 2006 20:59:51 -0500 (CDT) Original-Received: (from teirllm@localhost) by jane.dms.auburn.edu (8.13.4+Sun/8.13.3/Submit) id k3N1xpBu021881; Sat, 22 Apr 2006 20:59:51 -0500 (CDT) X-Authentication-Warning: jane.dms.auburn.edu: teirllm set sender to teirllm@dms.auburn.edu using -f Original-To: eliz@gnu.org In-reply-to: (message from Eli Zaretskii on Sat, 22 Apr 2006 16:15:50 +0300) 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:53248 Archived-At: Eli Zaretskii wrote" > Why? What's the _downside_ of adding a fudge factor to puresize? It makes the memory footprint larger. By a completely negligible percentage (a fraction of a percent), obviously not enough to worry about or waste any time on trying to reduce it further. Certainly not in the CVS version, where BASE_PURESIZE needs to be increased all the time and the only non-negligible effects of making the fudge factor even tinier are to increase the frequency of the required increases and to force most CVS user to increase the value locally if they have a very few small uninstalled changes. Comparing my present pure-bytes-used of 1200904 with the 1036280 from an old CVS version of 2005-02-07, suggests that pure-bytes-used is currently growing faster than 13 percent a year (between the the reference points I used it grew at an annualized rate of 13.7 percent). I do not know whether such a rate of growth constitutes a problem. I have no real figures, but I would guess that the amount of memory available on the average computer grows even faster than 14 percent a year, in which case the growth of pure-bytes-used does not represent a real problem. Anyway, whether the rate of growth of pure-bytes-used represents a problem or not, reducing the fudge-factor from a fraction of one percent to an even tinier fraction of one percent is completely meaningless. As long as that fudge factor stays within one percent, it stays negligible and does not contribute to the rate of growth. Sincerely, Luc.