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: [RFC] position caches Date: Thu, 14 Mar 2013 20:23:03 +0200 Message-ID: <837gl9j0xk.fsf@gnu.org> References: <513EDFAA.8030803@yandex.ru> <83k3pck0kv.fsf@gnu.org> <514162C1.5060508@yandex.ru> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1363285440 23755 80.91.229.3 (14 Mar 2013 18:24:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 14 Mar 2013 18:24:00 +0000 (UTC) Cc: emacs-devel@gnu.org To: Dmitry Antipov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Mar 14 19:24:19 2013 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 1UGCp8-0001Xc-8O for ged-emacs-devel@m.gmane.org; Thu, 14 Mar 2013 19:24:18 +0100 Original-Received: from localhost ([::1]:41572 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UGCol-0006Y2-Mm for ged-emacs-devel@m.gmane.org; Thu, 14 Mar 2013 14:23:55 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:34435) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UGCoi-0006UO-6u for emacs-devel@gnu.org; Thu, 14 Mar 2013 14:23:53 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UGCob-0006R2-IS for emacs-devel@gnu.org; Thu, 14 Mar 2013 14:23:52 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:50789) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UGCob-0006Qe-A9 for emacs-devel@gnu.org; Thu, 14 Mar 2013 14:23:45 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MJN00G00XOFCM00@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Thu, 14 Mar 2013 20:23:01 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MJN00GVZXQDCL00@a-mtaout22.012.net.il>; Thu, 14 Mar 2013 20:23:01 +0200 (IST) In-reply-to: <514162C1.5060508@yandex.ru> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.172 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:157866 Archived-At: > Date: Thu, 14 Mar 2013 09:40:17 +0400 > From: Dmitry Antipov > CC: emacs-devel@gnu.org > > On 03/12/2013 09:08 PM, Eli Zaretskii wrote: > > > Therefore, bidi.c needs to determine the paragraph start each time it > > enters a new paragraph. It needs to do that even if the buffer didn't > > change a bit, because a new paragraph can have a different base > > direction. The bidi_it->new_paragraph flag is set when the iteration > > goes out of a paragraph or when the iterator is re-seated far away of > > its current position. In those cases, xdisp.c calls > > bidi_paragraph_init, which in turn calls bidi_find_paragraph_start. > > You cannot return the beginning of previously found paragraph just > > because the buffer didn't change. > > I do not understand this. Sorry, this is entirely my fault: I failed to write something without which the above indeed makes no sense. > I'm trying to cache not just the previously > find paragraph start, but the previously find paragraph start against > [bidi_it->charpos, bidi_it->bytepos] buffer position; so if bidi_it is > moved in any way, cache becomes invalid even if the buffer is not changed. You are talking about the line marked below: > - while (pos_byte > BEGV_BYTE > - && n++ < MAX_PARAGRAPH_SEARCH > - && fast_looking_at (re, pos, pos_byte, limit, limit_byte, Qnil) < 0) > + if (valid_pos_cache (b, &b->bidi_paragraph_cache) > + && b->bidi_paragraph_cache.bufpos == pos_byte) <<<<<<<<<<<<<<<<< > + return b->bidi_paragraph_cache.posval; > + else Yes, this does invalidate the cache when the iterator moves, but it also makes the cache almost entirely useless, because the iterator moves all the time (that's why it's called "iterator"). It almost never needs to find the paragraph start starting at the same buffer position. I intended to tell you that this condition will render the caching much less useful than it could have been, but somehow forgot. This code runs when the iterator is "re-seated" to a different position in the buffer. An example which is frequently met, and thus might benefit from caching, is when the display code calls move_it_vertically and/or move_it_vertically_backward, which start by moving backwards one or more lines, and then start working from there. If the line we end up on is still within the same paragraph, being able to not search for paragraph start again is a big win. Another relevant example is the implementation of vertical-motion. Each time you press C-n or C-p, we call start_display, which forces the move_it_* routines called after that to look for the beginning of the current paragraph, starting at a line that is not the current one. Again per-buffer cache of the current paragraph would help here a lot, especially when lines in the buffer are very long. IOW, if you invalidate the cache whenever the iterator changes its position, keeping a separate cache for each buffer is redundant, because the next time we will display the same buffer, we will almost surely begin from a different buffer position. So to be useful, the cache cannot be invalidated so frequently. It should only be invalidated when we exit the paragraph, i.e. find ourselves before its beginning or after its end.