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: warn-maybe-out-of-memory Date: Mon, 14 Jul 2014 23:45:40 -0400 Message-ID: References: <83egxtax97.fsf@gnu.org> <83d2ddaw52.fsf@gnu.org> <53BF6B2F.5030701@yandex.ru> <837g3kbd9g.fsf@gnu.org> <53BFA3BB.6090709@yandex.ru> <8361j4b744.fsf@gnu.org> <53BFB1C3.9020202@yandex.ru> <5kpphafqd9.fsf@fencepost.gnu.org> <53C22ED8.5050206@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1405395980 10456 80.91.229.3 (15 Jul 2014 03:46:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 15 Jul 2014 03:46:20 +0000 (UTC) Cc: Eli Zaretskii , emacs-devel@gnu.org To: Dmitry Antipov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jul 15 05:46:13 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1X6tgx-0005FT-6B for ged-emacs-devel@m.gmane.org; Tue, 15 Jul 2014 05:46:11 +0200 Original-Received: from localhost ([::1]:32875 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X6tgw-0006ku-O8 for ged-emacs-devel@m.gmane.org; Mon, 14 Jul 2014 23:46:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56578) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X6tgn-0006kS-Hq for emacs-devel@gnu.org; Mon, 14 Jul 2014 23:46:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X6tgg-0001j7-2x for emacs-devel@gnu.org; Mon, 14 Jul 2014 23:46:01 -0400 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:59704) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X6tgX-0001an-RW; Mon, 14 Jul 2014 23:45:45 -0400 Original-Received: from fmsmemgm.homelinux.net (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id s6F3jeG3013110; Mon, 14 Jul 2014 23:45:42 -0400 Original-Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id 10B7AAE655; Mon, 14 Jul 2014 23:45:40 -0400 (EDT) In-Reply-To: <53C22ED8.5050206@yandex.ru> (Dmitry Antipov's message of "Sun, 13 Jul 2014 11:01:44 +0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV5003=0 X-NAI-Spam-Version: 2.3.0.9378 : core <5003> : inlines <1073> : streams <1238722> : uri <1791344> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.22 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:173029 Archived-At: >>> Here's another problem: what kind of "free memory" do you measure? > "Free" means "immediately available for allocation", i.e. not used by > OS or other processes for any purpose. If an OS should perform some > non-trivial action to get more memory (increase swap space or shrink > some internal data structures), this is not accounted as "free". Freeing space from the cache is a trivial action. The OS wants to keep as much stuff in the cache as it can, thus minimizing the "free" space, since "free" here basically means "wasted". If your "free" includes "free in RAM + free in swap" then it's marginally more useful ("free in RAM" will usually be close to 0, whereas "free in swap" should usually be fairly large), but I still can't think of a frequent enough configuration and situation where this would be useful enough to justify wasting code on it. >> The performance of Emacs is pretty poor with large files - the default >> large-file-warning-threshold is 10MB! > This may be subject to change without notice :-). If the user changes it, that's her choice, but notice that it is currently much smaller than anything your "out of memory" check could hope to detect, so if these small files are already considered problematic, trying to catch the "yet larger" case seems difficult to justify. Stefan