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: Region cache for bidi paragraphs? Date: Mon, 05 Aug 2013 18:18:09 +0300 Message-ID: <83siyow4i6.fsf@gnu.org> References: <51FB93C5.1020804@yandex.ru> <83bo5gyytp.fsf@gnu.org> <51FF378D.9000305@yandex.ru> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1375715928 21221 80.91.229.3 (5 Aug 2013 15:18:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 5 Aug 2013 15:18:48 +0000 (UTC) Cc: emacs-devel@gnu.org To: Dmitry Antipov , Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 05 17:18:49 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 1V6MYX-0005Gk-JQ for ged-emacs-devel@m.gmane.org; Mon, 05 Aug 2013 17:18:45 +0200 Original-Received: from localhost ([::1]:59420 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V6MYX-0004Y8-3S for ged-emacs-devel@m.gmane.org; Mon, 05 Aug 2013 11:18:45 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52969) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V6MYP-0004Mg-Iv for emacs-devel@gnu.org; Mon, 05 Aug 2013 11:18:42 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V6MYK-0002YE-4j for emacs-devel@gnu.org; Mon, 05 Aug 2013 11:18:37 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:33306) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V6MYJ-0002Xt-SB for emacs-devel@gnu.org; Mon, 05 Aug 2013 11:18:32 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MR200F00D4IO500@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Mon, 05 Aug 2013 18:18:01 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MR200F7ND61L340@a-mtaout20.012.net.il>; Mon, 05 Aug 2013 18:18:01 +0300 (IDT) In-reply-to: <51FF378D.9000305@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.166 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:162433 Archived-At: > Date: Mon, 05 Aug 2013 09:26:37 +0400 > From: Dmitry Antipov > CC: emacs-devel@gnu.org > > Input 0: xdisp.c > Input 1: ASCII text 30K lines, 1000chr/line, no paragraph separators > Input 2: ASCII text 30K lines, 1000chr/line, paragraph separator after each line > > Time is in seconds as reported, smaller is better. > > Input 0 1 0 cached 1 cached > -------+--------+--------+--------+------- > 0 30.2 12.7 30.4 12.7 > 1 11.1 34.5 6.4 15.3 > 2 6.0 13.1 5.2 13.1 > ------------------------------------------ > > I.e. longer lines and smaller amount of paragraph separators => > more benefits from using region cache. Thanks for the data. The gains sound marginal to me, especially given that the use case where the gains are tangible (Input 1, very long line and no paragraph separators anywhere in sight) doesn't look like a frequent use case. Even in that case you get a speedup of a few milliseconds per redisplay cycle. I'm not sure this is worth the extra complexity, but if Stefan thinks otherwise, I won't object. There's one problem with your suggestion that perhaps needs to be fixed before this is installed: you invalidate the cache on each modification of the buffer, so scrolling through a buffer in a mode that has font-lock set up will constantly invalidate the cache, since adding text properties constitutes a "modification" of the buffer text. When I scroll through xdisp.c, I see the breakpoint set where you invalidate the cache in insdel.c being constantly hit whenever Emacs scrolls some new text into view. Since most modes have font lock nowadays, I think leaving this unhandled will all but eliminate the gains in most use cases.