From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: warn-maybe-out-of-memory Date: Fri, 11 Jul 2014 12:02:51 +0300 Message-ID: <8361j4b744.fsf@gnu.org> References: <83egxtax97.fsf@gnu.org> <83d2ddaw52.fsf@gnu.org> <53BF6B2F.5030701@yandex.ru> <837g3kbd9g.fsf@gnu.org> <53BFA3BB.6090709@yandex.ru> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1405069446 15511 80.91.229.3 (11 Jul 2014 09:04:06 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 11 Jul 2014 09:04:06 +0000 (UTC) Cc: emacs-devel@gnu.org To: Dmitry Antipov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jul 11 11:03:58 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 1X5WkH-0003se-RZ for ged-emacs-devel@m.gmane.org; Fri, 11 Jul 2014 11:03:57 +0200 Original-Received: from localhost ([::1]:43194 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X5WkH-00054V-CS for ged-emacs-devel@m.gmane.org; Fri, 11 Jul 2014 05:03:57 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35379) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X5WjL-00043p-1y for emacs-devel@gnu.org; Fri, 11 Jul 2014 05:03:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X5WjB-0003GP-Hd for emacs-devel@gnu.org; Fri, 11 Jul 2014 05:02:58 -0400 Original-Received: from mtaout25.012.net.il ([80.179.55.181]:54092) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X5WjB-0003GJ-4B for emacs-devel@gnu.org; Fri, 11 Jul 2014 05:02:49 -0400 Original-Received: from conversion-daemon.mtaout25.012.net.il by mtaout25.012.net.il (HyperSendmail v2007.08) id <0N8J00H00I2N8N00@mtaout25.012.net.il> for emacs-devel@gnu.org; Fri, 11 Jul 2014 11:58:31 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout25.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N8J00FDCI9JNW20@mtaout25.012.net.il>; Fri, 11 Jul 2014 11:58:31 +0300 (IDT) In-reply-to: <53BFA3BB.6090709@yandex.ru> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.181 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:172970 Archived-At: > Date: Fri, 11 Jul 2014 12:43:39 +0400 > From: Dmitry Antipov > CC: emacs-devel@gnu.org > > On 07/11/2014 10:50 AM, Eli Zaretskii wrote: > > > But if this warning is to be useful, it should catch the majority of > > the cases, otherwise we are just wasting cycles. With the current > > test, many cases of visiting files that cannot be accommodated will go > > undetected, thus rendering all this feature useless. > > With this feature, I'm just trying to redirect user to `find-file-literally' > if file looks so large that `find-file-noselect' is likely to run out of > memory. What other cases do you mean? I mean the cases where the file size is borderline, near the available memory, but slightly less than that. > > Since it's only a warning that doesn't prevent visiting a file, it is > > better to err on the other side of the truth. E.g., apply some > > heuristics as to the average expansion factor, perhaps dependent on > > the locale. > > IIUC there are no reliable heuristics here. Heuristics doesn't have to be reliable, just plausible. Erring on the "safe side", which in this case means emitting the warning even when the file is actually not too large, is OK -- it's only a warning. > For example, produce_charset and compose_text may allocate > substantial amount of memory to represent `composition' and > `charset' extra properties Then by all means add that memory to the estimation, at least in locales that frequently do that. Or maybe even always. > and we need to read and decode everything to find all places where > such an extra properties should be attached. That's not the intent, granted. > > And don't forget that even for plain-ASCII files we > > allocate the gap in addition to the text itself, so the mere size of > > the file is simply _never_ the correct value, it is always an > > underestimation. IOW, this test is always biased towards lower > > values. > > Unless someone still uses a machine with 64K RAM, initial gap size > is very small in comparison with file sizes we're talking about. It is indeed very small, but it can easily cause the needed memory to cross the border. Adding it will catch these borderline cases, which AFAIU is the purpose of this feature. > We don't need to do "something like that", i.e. we don't need a precise > estimation. OSes are tricky about memory management; overall VM picture > may drastically change when file reading is in progress, etc. With a lot > of constraints you can't predict, estimate and control, precise estimation > just makes no sense. Then how does this feature make sense? It is, according to you, unpredictable and uncontrollable.