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: newline cache Date: Fri, 25 Apr 2014 12:20:06 +0300 Message-ID: <83iopxpxyx.fsf@gnu.org> References: <837g6id3mi.fsf@gnu.org> <838uqxb6o6.fsf@gnu.org> <837g6g9iip.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Content-Transfer-Encoding: 7BIT X-Trace: ger.gmane.org 1398417631 11013 80.91.229.3 (25 Apr 2014 09:20:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 25 Apr 2014 09:20:31 +0000 (UTC) Cc: emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Apr 25 11:20:24 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 1WdcIx-0006T0-8y for ged-emacs-devel@m.gmane.org; Fri, 25 Apr 2014 11:20:23 +0200 Original-Received: from localhost ([::1]:56765 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WdcIw-0002VO-Qr for ged-emacs-devel@m.gmane.org; Fri, 25 Apr 2014 05:20:22 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48358) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WdcIn-00024O-O7 for emacs-devel@gnu.org; Fri, 25 Apr 2014 05:20:19 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WdcIh-0000Kc-Ml for emacs-devel@gnu.org; Fri, 25 Apr 2014 05:20:13 -0400 Original-Received: from mtaout23.012.net.il ([80.179.55.175]:58083) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WdcIh-0000J0-F2; Fri, 25 Apr 2014 05:20:07 -0400 Original-Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0N4K00F00XF50Q00@a-mtaout23.012.net.il>; Fri, 25 Apr 2014 12:20:06 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N4K00FGIXXH0N10@a-mtaout23.012.net.il>; Fri, 25 Apr 2014 12:20:06 +0300 (IDT) Sun-Java-System-SMTP-Warning: Lines longer than SMTP allows found and truncated. In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.175 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:171624 Archived-At: > Date: Wed, 23 Apr 2014 20:33:10 -0400 > From: Richard Stallman > Cc: emacs-devel@gnu.org > > I suggest to try it; you might be surprised. I tried it on a 7MB mbox > file, and didn't see any significant slowdown. The reason is simple: > the mbox buffer is almost always narrowed, and find_newline, which is > the workhorse of the function I wrote, and also the main suspect, only > looks within the restriction. > > Well, I could arrange to narrow to the current message > before running the test. Maybe that will do enough. Some additional info about this. I didn't install newline-cache-check in a post-command-hook, primarily because I was unsure which buffer to check the cache in. Instead, I waited for some problem to happen first. This came in the form of a qp-encoded mail that Rmail didn't succeed in decoding for display, complaining thusly: Warning: corrupt attribute header in message I then invoked newline-cache-check in INBOX, which came up OK. Next, I invoked newline-cache-check in " *message-viewer INBOX*", and bingo: it detected a corruption. The viewer buffer is narrowed to a single email message, as it should be. The cache thinks that there are only 2 newlines in the narrowed region, while the truth is there are much more, and what the cache thinks is actually a tiny subset of the truth: (newline-cache-check (get-buffer " *message-viewer INBOX*")) => [[27793944 27797783] [27788878 27788912 27788938 27788985 27789043 27789110 27789123 27789161 27789182 27789233 27789306 27789344 27789365 27789416 27789488 27789503 27789575 27789645 27789660 27789731 27789771 27789809 27789830 27789881 27789986 27790091 27790187 27790220 27790282 27790355 27790836 27790897 27790959 27791021 27791083 27791145 27791207 27791269 27791331 27791393 27791455 27791486 27791590 27792014 27792056 27792563 27792636 27792680 27792719 27792762 27792840 27792873 27792947 27792965 27793010 27793054 27793112 27793144 27793173 27793174 27793251 27793328 27793405 27793482 27793559 27793636 27793713 27793790 27793867 27793944 27794020 27794097 27794174 27794251 27794328 27794405 27794482 27794559 27794635 27794712 27794789 27794866 27794943 27795020 27795097 27795174 27795251 27795328 27795405 27795482 27795559 27795636 27795713 27795788 27795863 27795939 27796015 27796091 27796166 27796243 27796320 27796397 27796474 27796551 27796628 27796705 27796782 27796859 So now I will install a check in post-command-hook and try to see what causes the corruption. (As you see, my Rmail buffer is very large, about 29MB, but I don't think it matters, because the check is always done in a region narrowed to a single email message, and how large can that be?)