From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 07 16:24:22 2013 Received: (at submit) by debbugs.gnu.org; 7 Oct 2013 20:24:22 +0000 Received: from localhost ([127.0.0.1]:32823 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VTHLn-0001o7-8D for submit@debbugs.gnu.org; Mon, 07 Oct 2013 16:24:21 -0400 Received: from eggs.gnu.org ([208.118.235.92]:57081) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VTH4R-0001N5-Gc for submit@debbugs.gnu.org; Mon, 07 Oct 2013 16:06:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VTH4G-0003db-I4 for submit@debbugs.gnu.org; Mon, 07 Oct 2013 16:06:23 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: *** X-Spam-Status: No, score=3.6 required=5.0 tests=BAYES_50, UNWANTED_LANGUAGE_BODY,WEIRD_QUOTING autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:55010) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VTH4G-0003dK-ER for submit@debbugs.gnu.org; Mon, 07 Oct 2013 16:06:12 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58729) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VTH47-0008M1-F8 for bug-gnu-emacs@gnu.org; Mon, 07 Oct 2013 16:06:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VTH3v-0003FE-7U for bug-gnu-emacs@gnu.org; Mon, 07 Oct 2013 16:06:03 -0400 Received: from e8.ny.us.ibm.com ([32.97.182.138]:48484) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VTH3u-0003Dw-Pd for bug-gnu-emacs@gnu.org; Mon, 07 Oct 2013 16:05:51 -0400 Received: from /spool/local by e8.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 7 Oct 2013 16:05:48 -0400 Received: from d01dlp02.pok.ibm.com (9.56.250.167) by e8.ny.us.ibm.com (192.168.1.108) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 7 Oct 2013 16:05:47 -0400 Received: from b01cxnp22036.gho.pok.ibm.com (b01cxnp22036.gho.pok.ibm.com [9.57.198.26]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 9A96F6E8060 for ; Mon, 7 Oct 2013 16:05:44 -0400 (EDT) Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by b01cxnp22036.gho.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r97K5iL8459054 for ; Mon, 7 Oct 2013 20:05:44 GMT Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r97K5he9028210 for ; Mon, 7 Oct 2013 17:05:43 -0300 Received: from d01ml605.pok.ibm.com (d01ml605.pok.ibm.com [9.63.8.148]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id r97K5hJq028204 for ; Mon, 7 Oct 2013 17:05:43 -0300 MIME-Version: 1.0 X-TNEFEvaluated: 1 Subject: 24.3; Bidirectional display very slow with long lines To: bug-gnu-emacs@gnu.org, bug-gnu-emacs@gnu.org Message-ID: From: Jerome L Quinn Date: Mon, 7 Oct 2013 16:05:42 -0400 X-MIMETrack: Serialize by Router on D01ML605/01/M/IBM(Release 9.0IF2 |July 03, 2013) at 10/07/2013 04:05:43 PM, Serialize complete at 10/07/2013 04:05:43 PM Content-Transfer-Encoding: base64 Content-Type: text/plain; charset=utf-8 X-TM-AS-MML: No X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13100720-0320-0000-0000-000001451777 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.0 (----) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Mon, 07 Oct 2013 16:24:16 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.0 (----) SWYgSSBoYXZlIGEgYnVmZmVyIHdpdGggYSB2ZXJ5IGxvbmcgbGluZSAoMTQwMDAgY2hhcnMpIHdp dGggYSBtaXggb2YNCkFTQ0lJIGFuZCBBcmFiaWMgdGV4dCwgZW1hY3MgZ2V0cyBwYWluZnVsbHkg c2xvdyB3aGVuIHBvaW50IGlzIGZ1cnRoZXINCmFsb25nIHRoZSBsaW5lLiAgSXQgbG9va3MgbGlr ZSB0aGVyZSdzIGFuIE5eMiBhbGdvcml0aG0gZGVwZW5kZW50IG9uIHRoZQ0KY29sdW1uIG9mIHBv aW50LiAgV2UgZW5jb3VudGVyIHRoaXMga2luZCBvZiBkYXRhIGluIG91ciB3b3JrIGxvb2tpbmcg YXQNCmdlbmVyYXRlZCBmaWxlcy4gIFRoZSBvbmx5IHNvbHV0aW9uIGF0IHRoZSBtb21lbnQgaXMg dG8gZGlzYWJsZQ0KYmlkaXJlY3Rpb25hbCByZW9yZGVyaW5nLg0KDQpUaGVyZSBhcmUgYWxzbyBw cm9ibGVtcyB3aXRoIHRoZSBkaXNwbGF5LiAgSWYgeW91IHNlYXJjaCBmb3IgdGhlIGZvbGxvd2lu ZzoNCg0KNzQsMzQ2LDM0Nw0KDQpteSBkaXNwbGF5IGxvb2tzIGxpa2U6DQoNCi4uLiAsW1siNzQs MzQ2LDM0N10sIi4iLCIuIiwiIiwiLiJdLCAuLi4NCg0KV2hlcmVhcyBpdCBzaG91bGQgZGlzcGxh eToNCg0KLi4uICxbIi4iLCIiLCIuIiwiLiIsWzc0LDM0NiwzNDddXV1dLCAuLi4NCg0KTm90ZSB0 aGF0IHRoZSBmaXJzdCAiIGlzIG1pc3BsYWNlZCwgZXZlbiBpZiB5b3UgYWNjZXB0IHRoYXQgdGhl IHJlc3QNCnNob3VsZCBiZSByZXZlcnNlZC4NCg0KVGhlIGZvbGxvd2luZyBpcyBteSBleGFtcGxl IHRleHQ6DQoNCltbbnVsbCxbInJhdyJdLFtbItmD2YQg2YfYsNinINin2YTZg9ix2YfYjCDZgdin 2KbYtiDYp9mE2YPYsdin2YfZitipINit2KfZhNipINi62KjZitipINiq2YTZgdmG2Kcg2YXZhiDZ g9mEINis2KfZhtio2Iwg2LnZhtiv2YXYpyDZitiq2YXZhti32YIg2KfZhNio2LnYtiDYqNin2YTZ g9ix2KfZh9mK2KnYjCDYudmG2K/ZhdinINmK2LnYqtmF2YQg2KfZhNir2KPYsSDZgdmJINin2YTZ htmB2YjYs9iMINiq2LXZitixINmC2YbYp9io2YQg2KjYtNix2YrYqSDYqtmF2LTZiSDYudmE2Ykg 2YLYr9mF2YrZhtiMINil2YYg2LHYo9iqINmG2KfYsdinINiq2LXYqCDZhdmGINmG2YHZiNiz2YfY pyDYqNmG2LLZitmG2KfYjCDYp9mE2YPYsdin2YfZitipINit2KfZhNipINmF2LHYttmK2Kkg2KrY s9iq2KjYryDYqNin2YTZiNi32YbYjCDYqti52KjZitixINmD2KfYsdmHINi52YYg2LrYttioINmF 2LPYqti32YrYsS4uINmE2Kcg2YrZgdix2YIg2YPYq9mK2LHYpyDYudmGINin2YTYtNix2LEg2KfZ hNmF2LPYqti32YrYsdiMINmG2YrYsdin2YYg2KfZhNmD2LHYp9mH2YrYqSDYqti52KrZhdmEINmB 2Ykg2KfZhNi12K/ZiNix2Iwg2K3ZhdmFINmE2Ygg2KrYudmE2YXZiNmGLiIsWy0xLDAsMzIyXV1d XSxbInJhdyIsWyJyYXd0ZXh0Il0sW1si2YPZhCDZh9iw2Kcg2KfZhNmD2LHZh9iMINmB2KfYpti2 INin2YTZg9ix2KfZh9mK2Kkg2K3Yp9mE2Kkg2LrYqNmK2Kkg2KrZhNmB2YbYpyDZhdmGINmD2YQg 2KzYp9mG2KjYjCDYudmG2K/ZhdinINmK2KrZhdmG2LfZgiDYp9mE2KjYudi2INio2KfZhNmD2LHY p9mH2YrYqdiMINi52YbYr9mF2Kcg2YrYudiq2YXZhCDYp9mE2KvYo9ixINmB2Ykg2KfZhNmG2YHZ iNiz2Iwg2KrYtdmK2LEg2YLZhtin2KjZhCDYqNi02LHZitipINiq2YXYtNmJINi52YTZiSDZgtiv 2YXZitmG2Iwg2KXZhiDYsdij2Kog2YbYp9ix2Kcg2KrYtdioINmF2YYg2YbZgdmI2LPZh9inINio 2YbYstmK2YbYp9iMINin2YTZg9ix2KfZh9mK2Kkg2K3Yp9mE2Kkg2YXYsdi22YrYqSDYqtiz2KrY qNivINio2KfZhNmI2LfZhtiMINiq2LnYqNmK2LEg2YPYp9ix2Ycg2LnZhiDYuti22Kgg2YXYs9iq 2LfZitixLi4g2YTYpyDZitmB2LHZgiDZg9ir2YrYsdinINi52YYg2KfZhNi02LHYsSDYp9mE2YXY s9iq2LfZitix2Iwg2YbZitix2KfZhiDYp9mE2YPYsdin2YfZitipINiq2LnYqtmF2YQg2YHZiSDY p9mE2LXYr9mI2LHYjCDYrdmF2YUg2YTZiCDYqti52YTZhdmI2YYuIixbMCwwLDMyMl1dXV0sWyJy YXd0ZXh0IixbInRleHQiXSxbWyLZg9mEINmH2LDYpyDYp9mE2YPYsdmH2Iwg2YHYp9im2LYg2KfZ hNmD2LHYp9mH2YrYqSDYrdin2YTYqSDYutio2YrYqSDYqtmE2YHZhtinINmF2YYg2YPZhCDYrNin 2YbYqNiMINi52YbYr9mF2Kcg2YrYqtmF2YbYt9mCINin2YTYqNi52LYg2KjYp9mE2YPYsdin2YfZ itip2Iwg2LnZhtiv2YXYpyDZiti52KrZhdmEINin2YTYq9ij2LEg2YHZiSDYp9mE2YbZgdmI2LPY jCDYqti12YrYsSDZgtmG2KfYqNmEINio2LTYsdmK2Kkg2KrZhdi02Ykg2LnZhNmJINmC2K/ZhdmK 2YbYjCDYpdmGINix2KPYqiDZhtin2LHYpyDYqti12Kgg2YXZhiDZhtmB2YjYs9mH2Kcg2KjZhtiy 2YrZhtin2Iwg2KfZhNmD2LHYp9mH2YrYqSDYrdin2YTYqSDZhdix2LbZitipINiq2LPYqtio2K8g 2KjYp9mE2YjYt9mG2Iwg2KrYudio2YrYsSDZg9in2LHZhyDYudmGINi62LbYqCDZhdiz2KrYt9mK 2LEuLiDZhNinINmK2YHYsdmCINmD2KvZitix2Kcg2LnZhiDYp9mE2LTYsdixINin2YTZhdiz2KrY t9mK2LHYjCDZhtmK2LHYp9mGINin2YTZg9ix2KfZh9mK2Kkg2KrYudiq2YXZhCDZgdmJINin2YTY tdiv2YjYsdiMINit2YXZhSDZhNmIINiq2LnZhNmF2YjZhi4iLFswLDAsMzIyXV1dXSxbInRleHQi LFsicmF3dG9rIiwidG9rdHlwZSJdLFtbItmD2YQiLCIwIixbMCwwLDJdXSxbItmH2LDYpyIsIjAi LFswLDMsNl1dLFsi2KfZhNmD2LHZhyIsIjAiLFswLDcsMTJdXSxbItiMIiwiMjA0OCIsWzAsMTIs MTNdXSxbItmB2KfYpti2IiwiMCIsWzAsMTQsMThdXSxbItin2YTZg9ix2KfZh9mK2KkiLCIwIixb MCwxOSwyN11dLFsi2K3Yp9mE2KkiLCIwIixbMCwyOCwzMl1dLFsi2LrYqNmK2KkiLCIwIixbMCwz MywzN11dLFsi2KrZhNmB2YbYpyIsIjAiLFswLDM4LDQzXV0sWyLZhdmGIiwiMCIsWzAsNDQsNDZd XSxbItmD2YQiLCIwIixbMCw0Nyw0OV1dLFsi2KzYp9mG2KgiLCIwIixbMCw1MCw1NF1dLFsi2Iwi LCIyMDQ4IixbMCw1NCw1NV1dLFsi2LnZhtiv2YXYpyIsIjAiLFswLDU2LDYxXV0sWyLZitiq2YXZ hti32YIiLCIwIixbMCw2Miw2OF1dLFsi2KfZhNio2LnYtiIsIjAiLFswLDY5LDc0XV0sWyLYqNin 2YTZg9ix2KfZh9mK2KkiLCIwIixbMCw3NSw4NF1dLFsi2IwiLCIyMDQ4IixbMCw4NCw4NV1dLFsi 2LnZhtiv2YXYpyIsIjAiLFswLDg2LDkxXV0sWyLZiti52KrZhdmEIiwiMCIsWzAsOTIsOTddXSxb Itin2YTYq9ij2LEiLCIwIixbMCw5OCwxMDNdXSxbItmB2YkiLCIwIixbMCwxMDQsMTA2XV0sWyLY p9mE2YbZgdmI2LMiLCIwIixbMCwxMDcsMTEzXV0sWyLYjCIsIjIwNDgiLFswLDExMywxMTRdXSxb Itiq2LXZitixIiwiMCIsWzAsMTE1LDExOV1dLFsi2YLZhtin2KjZhCIsIjAiLFswLDEyMCwxMjVd XSxbItio2LTYsdmK2KkiLCIwIixbMCwxMjYsMTMxXV0sWyLYqtmF2LTZiSIsIjAiLFswLDEzMiwx MzZdXSxbIti52YTZiSIsIjAiLFswLDEzNywxNDBdXSxbItmC2K/ZhdmK2YYiLCIwIixbMCwxNDEs MTQ2XV0sWyLYjCIsIjIwNDgiLFswLDE0NiwxNDddXSxbItil2YYiLCIwIixbMCwxNDgsMTUwXV0s WyLYsdij2KoiLCIwIixbMCwxNTEsMTU0XV0sWyLZhtin2LHYpyIsIjAiLFswLDE1NSwxNTldXSxb Itiq2LXYqCIsIjAiLFswLDE2MCwxNjNdXSxbItmF2YYiLCIwIixbMCwxNjQsMTY2XV0sWyLZhtmB 2YjYs9mH2KciLCIwIixbMCwxNjcsMTczXV0sWyLYqNmG2LLZitmG2KciLCIwIixbMCwxNzQsMTgw XV0sWyLYjCIsIjIwNDgiLFswLDE4MCwxODFdXSxbItin2YTZg9ix2KfZh9mK2KkiLCIwIixbMCwx ODIsMTkwXV0sWyLYrdin2YTYqSIsIjAiLFswLDE5MSwxOTVdXSxbItmF2LHYttmK2KkiLCIwIixb MCwxOTYsMjAxXV0sWyLYqtiz2KrYqNivIiwiMCIsWzAsMjAyLDIwN11dLFsi2KjYp9mE2YjYt9mG IiwiMCIsWzAsMjA4LDIxNF1dLFsi2IwiLCIyMDQ4IixbMCwyMTQsMjE1XV0sWyLYqti52KjZitix IiwiMCIsWzAsMjE2LDIyMV1dLFsi2YPYp9ix2YciLCIwIixbMCwyMjIsMjI2XV0sWyLYudmGIiwi MCIsWzAsMjI3LDIyOV1dLFsi2LrYttioIiwiMCIsWzAsMjMwLDIzM11dLFsi2YXYs9iq2LfZitix IiwiMCIsWzAsMjM0LDI0MF1dLFsiLi4iLCIwIixbMCwyNDAsMjQyXV0sWyLZhNinIiwiMCIsWzAs MjQzLDI0NV1dLFsi2YrZgdix2YIiLCIwIixbMCwyNDYsMjUwXV0sWyLZg9ir2YrYsdinIiwiMCIs WzAsMjUxLDI1Nl1dLFsi2LnZhiIsIjAiLFswLDI1NywyNTldXSxbItin2YTYtNix2LEiLCIwIixb MCwyNjAsMjY1XV0sWyLYp9mE2YXYs9iq2LfZitixIiwiMCIsWzAsMjY2LDI3NF1dLFsi2IwiLCIy MDQ4IixbMCwyNzQsMjc1XV0sWyLZhtmK2LHYp9mGIiwiMCIsWzAsMjc2LDI4MV1dLFsi2KfZhNmD 2LHYp9mH2YrYqSIsIjAiLFswLDI4MiwyOTBdXSxbItiq2LnYqtmF2YQiLCIwIixbMCwyOTEsMjk2 XV0sWyLZgdmJIiwiMCIsWzAsMjk3LDI5OV1dLFsi2KfZhNi12K/ZiNixIiwiMCIsWzAsMzAwLDMw Nl1dLFsi2IwiLCIyMDQ4IixbMCwzMDYsMzA3XV0sWyLYrdmF2YUiLCIwIixbMCwzMDgsMzExXV0s WyLZhNmIIiwiMCIsWzAsMzEyLDMxNF1dLFsi2KrYudmE2YXZiNmGIiwiMCIsWzAsMzE1LDMyMV1d LFsiLiIsIjYxNDQiLFswLDMyMSwzMjJdXV1dLFsicmF3dG9rIixbInRvayJdLFtbItmD2YQiLFsw LDAsMl1dLFsi2YfYsNinIixbMSwzLDZdXSxbItin2YTZg9ix2YciLFsyLDcsMTJdXSxbIiwiLFsz LDEzLDE0XV0sWyLZgdin2KbYtiIsWzQsMTUsMTldXSxbItin2YTZg9ix2KfZh9mK2KkiLFs1LDIw LDI4XV0sWyLYrdin2YTYqSIsWzYsMjksMzNdXSxbIti62KjZitipIixbNywzNCwzOF1dLFsi2KrZ hNmB2YbYpyIsWzgsMzksNDRdXSxbItmF2YYiLFs5LDQ1LDQ3XV0sWyLZg9mEIixbMTAsNDgsNTBd XSxbItis2KfZhtioIixbMTEsNTEsNTVdXSxbIiwiLFsxMiw1Niw1N11dLFsi2LnZhtiv2YXYpyIs WzEzLDU4LDYzXV0sWyLZitiq2YXZhti32YIiLFsxNCw2NCw3MF1dLFsi2KfZhNio2LnYtiIsWzE1 LDcxLDc2XV0sWyLYqNin2YTZg9ix2KfZh9mK2KkiLFsxNiw3Nyw4Nl1dLFsiLCIsWzE3LDg3LDg4 XV0sWyLYudmG2K/ZhdinIixbMTgsODksOTRdXSxbItmK2LnYqtmF2YQiLFsxOSw5NSwxMDBdXSxb Itin2YTYq9ij2LEiLFsyMCwxMDEsMTA2XV0sWyLZgdmJIixbMjEsMTA3LDEwOV1dLFsi2KfZhNmG 2YHZiNizIixbMjIsMTEwLDExNl1dLFsiLCIsWzIzLDExNywxMThdXSxbItiq2LXZitixIixbMjQs MTE5LDEyM11dLFsi2YLZhtin2KjZhCIsWzI1LDEyNCwxMjldXSxbItio2LTYsdmK2KkiLFsyNiwx MzAsMTM1XV0sWyLYqtmF2LTZiSIsWzI3LDEzNiwxNDBdXSxbIti52YTZiSIsWzI4LDE0MSwxNDRd XSxbItmC2K/ZhdmK2YYiLFsyOSwxNDUsMTUwXV0sWyIsIixbMzAsMTUxLDE1Ml1dLFsi2KXZhiIs WzMxLDE1MywxNTVdXSxbItix2KPYqiIsWzMyLDE1NiwxNTldXSxbItmG2KfYsdinIixbMzMsMTYw LDE2NF1dLFsi2KrYtdioIixbMzQsMTY1LDE2OF1dLFsi2YXZhiIsWzM1LDE2OSwxNzFdXSxbItmG 2YHZiNiz2YfYpyIsWzM2LDE3MiwxNzhdXSxbItio2YbYstmK2YbYpyIsWzM3LDE3OSwxODVdXSxb IiwiLFszOCwxODYsMTg3XV0sWyLYp9mE2YPYsdin2YfZitipIixbMzksMTg4LDE5Nl1dLFsi2K3Y p9mE2KkiLFs0MCwxOTcsMjAxXV0sWyLZhdix2LbZitipIixbNDEsMjAyLDIwN11dLFsi2KrYs9iq 2KjYryIsWzQyLDIwOCwyMTNdXSxbItio2KfZhNmI2LfZhiIsWzQzLDIxNCwyMjBdXSxbIiwiLFs0 NCwyMjEsMjIyXV0sWyLYqti52KjZitixIixbNDUsMjIzLDIyOF1dLFsi2YPYp9ix2YciLFs0Niwy MjksMjMzXV0sWyLYudmGIixbNDcsMjM0LDIzNl1dLFsi2LrYttioIixbNDgsMjM3LDI0MF1dLFsi 2YXYs9iq2LfZitixIixbNDksMjQxLDI0N11dLFsiLi4iLFs1MCwyNDgsMjUwXV0sWyLZhNinIixb NTEsMjUxLDI1M11dLFsi2YrZgdix2YIiLFs1MiwyNTQsMjU4XV0sWyLZg9ir2YrYsdinIixbNTMs MjU5LDI2NF1dLFsi2LnZhiIsWzU0LDI2NSwyNjddXSxbItin2YTYtNix2LEiLFs1NSwyNjgsMjcz XV0sWyLYp9mE2YXYs9iq2LfZitixIixbNTYsMjc0LDI4Ml1dLFsiLCIsWzU3LDI4MywyODRdXSxb ItmG2YrYsdin2YYiLFs1OCwyODUsMjkwXV0sWyLYp9mE2YPYsdin2YfZitipIixbNTksMjkxLDI5 OV1dLFsi2KrYudiq2YXZhCIsWzYwLDMwMCwzMDVdXSxbItmB2YkiLFs2MSwzMDYsMzA4XV0sWyLY p9mE2LXYr9mI2LEiLFs2MiwzMDksMzE1XV0sWyIsIixbNjMsMzE2LDMxN11dLFsi2K3ZhdmFIixb NjQsMzE4LDMyMV1dLFsi2YTZiCIsWzY1LDMyMiwzMjRdXSxbItiq2LnZhNmF2YjZhiIsWzY2LDMy NSwzMzFdXSxbIi4iLFs2NywzMzIsMzMzXV1dXSxbInRvayIsWyJyYXdhdGIiXSxbWyLZg9mEIixb MCwwLDJdXSxbItmH2LDYpyIsWzEsMyw2XV0sWyLYp9mE2YPYsdmHIixbMiw3LDEyXV0sWyIsIixb MywxMywxNF1dLFsi2YHYp9im2LYiLFs0LDE1LDE5XV0sWyLYp9mE2YPYsdin2YfZitipIixbNSwy MCwyOF1dLFsi2K3Yp9mE2KkiLFs2LDI5LDMzXV0sWyLYutio2YrYqSIsWzcsMzQsMzhdXSxbItiq 2YTZgSIsWzgsMzksNDJdXSxbIivZhtinIixbOCw0Miw0NF1dLFsi2YXZhiIsWzksNDUsNDddXSxb ItmD2YQiLFsxMCw0OCw1MF1dLFsi2KzYp9mG2KgiLFsxMSw1MSw1NV1dLFsiLCIsWzEyLDU2LDU3 XV0sWyLYudmG2K8iLFsxMyw1OCw2MV1dLFsiK9mF2KciLFsxMyw2MSw2M11dLFsi2YrYqtmF2YbY t9mCIixbMTQsNjQsNzBdXSxbItin2YTYqNi52LYiLFsxNSw3MSw3Nl1dLFsi2KgjIixbMTYsNzcs NzhdXSxbItin2YTZg9ix2KfZh9mK2KkiLFsxNiw3OCw4Nl1dLFsiLCIsWzE3LDg3LDg4XV0sWyLY udmG2K8iLFsxOCw4OSw5Ml1dLFsiK9mF2KciLFsxOCw5Miw5NF1dLFsi2YrYudiq2YXZhCIsWzE5 LDk1LDEwMF1dLFsi2KfZhNir2KPYsSIsWzIwLDEwMSwxMDZdXSxbItmB2YkiLFsyMSwxMDcsMTA5 XV0sWyLYp9mE2YbZgdmI2LMiLFsyMiwxMTAsMTE2XV0sWyIsIixbMjMsMTE3LDExOF1dLFsi2KrY tdmK2LEiLFsyNCwxMTksMTIzXV0sWyLZgtmG2KfYqNmEIixbMjUsMTI0LDEyOV1dLFsi2KjYtNix 2YrYqSIsWzI2LDEzMCwxMzVdXSxbItiq2YXYtNmJIixbMjcsMTM2LDE0MF1dLFsi2LnZhNmJIixb MjgsMTQxLDE0NF1dLFsi2YLYr9mF2YrZhiIsWzI5LDE0NSwxNTBdXSxbIiwiLFszMCwxNTEsMTUy XV0sWyLYpdmGIixbMzEsMTUzLDE1NV1dLFsi2LHYo9iqIixbMzIsMTU2LDE1OV1dLFsi2YbYp9ix 2KciLFszMywxNjAsMTY0XV0sWyLYqti12KgiLFszNCwxNjUsMTY4XV0sWyLZhdmGIixbMzUsMTY5 LDE3MV1dLFsi2YbZgdmI2LMiLFszNiwxNzIsMTc2XV0sWyIr2YfYpyIsWzM2LDE3NiwxNzhdXSxb Itio2YbYstmK2YbYpyIsWzM3LDE3OSwxODVdXSxbIiwiLFszOCwxODYsMTg3XV0sWyLYp9mE2YPY sdin2YfZitipIixbMzksMTg4LDE5Nl1dLFsi2K3Yp9mE2KkiLFs0MCwxOTcsMjAxXV0sWyLZhdix 2LbZitipIixbNDEsMjAyLDIwN11dLFsi2KrYs9iq2KjYryIsWzQyLDIwOCwyMTNdXSxbItioIyIs WzQzLDIxNCwyMTVdXSxbItin2YTZiNi32YYiLFs0MywyMTUsMjIwXV0sWyIsIixbNDQsMjIxLDIy Ml1dLFsi2KrYudio2YrYsSIsWzQ1LDIyMywyMjhdXSxbItmD2KfYsSIsWzQ2LDIyOSwyMzJdXSxb IivZhyIsWzQ2LDIzMiwyMzNdXSxbIti52YYiLFs0NywyMzQsMjM2XV0sWyLYuti22KgiLFs0OCwy MzcsMjQwXV0sWyLZhdiz2KrYt9mK2LEiLFs0OSwyNDEsMjQ3XV0sWyIuLiIsWzUwLDI0OCwyNTBd XSxbItmE2KciLFs1MSwyNTEsMjUzXV0sWyLZitmB2LHZgiIsWzUyLDI1NCwyNThdXSxbItmD2KvZ itix2KciLFs1MywyNTksMjY0XV0sWyLYudmGIixbNTQsMjY1LDI2N11dLFsi2KfZhNi02LHYsSIs WzU1LDI2OCwyNzNdXSxbItin2YTZhdiz2KrYt9mK2LEiLFs1NiwyNzQsMjgyXV0sWyIsIixbNTcs MjgzLDI4NF1dLFsi2YbZitix2KfZhiIsWzU4LDI4NSwyOTBdXSxbItin2YTZg9ix2KfZh9mK2Kki LFs1OSwyOTEsMjk5XV0sWyLYqti52KrZhdmEIixbNjAsMzAwLDMwNV1dLFsi2YHZiSIsWzYxLDMw NiwzMDhdXSxbItin2YTYtdiv2YjYsSIsWzYyLDMwOSwzMTVdXSxbIiwiLFs2MywzMTYsMzE3XV0s WyLYrdmF2YUiLFs2NCwzMTgsMzIxXV0sWyLZhNmIIixbNjUsMzIyLDMyNF1dLFsi2KrYudmE2YXZ iNmGIixbNjYsMzI1LDMzMV1dLFsiLiIsWzY3LDMzMiwzMzNdXV1dLFsicmF3YXRiIixbImF0YiJd LFtbItmD2YQiLFswLDAsMl1dLFsi2YfYsNinIixbMSwzLDZdXSxbItin2YTZg9ix2YciLFsyLDcs MTJdXSxbIiwiLFszLDEzLDE0XV0sWyLZgdin2KbYtiIsWzQsMTUsMTldXSxbItin2YTZg9ix2KfZ h9mK2KkiLFs1LDIwLDI4XV0sWyLYrdin2YTYqSIsWzYsMjksMzNdXSxbIti62KjZitipIixbNywz NCwzOF1dLFsi2KrZhNmBIixbOCwzOSw0Ml1dLFsiK9mG2KciLFs5LDQzLDQ2XV0sWyLZhdmGIixb MTAsNDcsNDldXSxbItmD2YQiLFsxMSw1MCw1Ml1dLFsi2KzYp9mG2KgiLFsxMiw1Myw1N11dLFsi LCIsWzEzLDU4LDU5XV0sWyLYudmG2K8iLFsxNCw2MCw2M11dLFsiK9mF2KciLFsxNSw2NCw2N11d LFsi2YrYqtmF2YbYt9mCIixbMTYsNjgsNzRdXSxbItin2YTYqNi52LYiLFsxNyw3NSw4MF1dLFsi 2KgjIixbMTgsODEsODNdXSxbItin2YTZg9ix2KfZh9mK2KkiLFsxOSw4NCw5Ml1dLFsiLCIsWzIw LDkzLDk0XV0sWyLYudmG2K8iLFsyMSw5NSw5OF1dLFsiK9mF2KciLFsyMiw5OSwxMDJdXSxbItmK 2LnYqtmF2YQiLFsyMywxMDMsMTA4XV0sWyLYp9mE2KvYo9ixIixbMjQsMTA5LDExNF1dLFsi2YHZ iSIsWzI1LDExNSwxMTddXSxbItin2YTZhtmB2YjYsyIsWzI2LDExOCwxMjRdXSxbIiwiLFsyNywx MjUsMTI2XV0sWyLYqti12YrYsSIsWzI4LDEyNywxMzFdXSxbItmC2YbYp9io2YQiLFsyOSwxMzIs MTM3XV0sWyLYqNi02LHZitipIixbMzAsMTM4LDE0M11dLFsi2KrZhdi02YkiLFszMSwxNDQsMTQ4 XV0sWyLYudmE2YkiLFszMiwxNDksMTUyXV0sWyLZgtiv2YXZitmGIixbMzMsMTUzLDE1OF1dLFsi LCIsWzM0LDE1OSwxNjBdXSxbItil2YYiLFszNSwxNjEsMTYzXV0sWyLYsdij2KoiLFszNiwxNjQs MTY3XV0sWyLZhtin2LHYpyIsWzM3LDE2OCwxNzJdXSxbItiq2LXYqCIsWzM4LDE3MywxNzZdXSxb ItmF2YYiLFszOSwxNzcsMTc5XV0sWyLZhtmB2YjYsyIsWzQwLDE4MCwxODRdXSxbIivZh9inIixb NDEsMTg1LDE4OF1dLFsi2KjZhtiy2YrZhtinIixbNDIsMTg5LDE5NV1dLFsiLCIsWzQzLDE5Niwx OTddXSxbItin2YTZg9ix2KfZh9mK2KkiLFs0NCwxOTgsMjA2XV0sWyLYrdin2YTYqSIsWzQ1LDIw NywyMTFdXSxbItmF2LHYttmK2KkiLFs0NiwyMTIsMjE3XV0sWyLYqtiz2KrYqNivIixbNDcsMjE4 LDIyM11dLFsi2KgjIixbNDgsMjI0LDIyNl1dLFsi2KfZhNmI2LfZhiIsWzQ5LDIyNywyMzJdXSxb IiwiLFs1MCwyMzMsMjM0XV0sWyLYqti52KjZitixIixbNTEsMjM1LDI0MF1dLFsi2YPYp9ixIixb NTIsMjQxLDI0NF1dLFsiK9mHIixbNTMsMjQ1LDI0N11dLFsi2LnZhiIsWzU0LDI0OCwyNTBdXSxb Iti62LbYqCIsWzU1LDI1MSwyNTRdXSxbItmF2LPYqti32YrYsSIsWzU2LDI1NSwyNjFdXSxbIi4u IixbNTcsMjYyLDI2NF1dLFsi2YTYpyIsWzU4LDI2NSwyNjddXSxbItmK2YHYsdmCIixbNTksMjY4 LDI3Ml1dLFsi2YPYq9mK2LHYpyIsWzYwLDI3MywyNzhdXSxbIti52YYiLFs2MSwyNzksMjgxXV0s WyLYp9mE2LTYsdixIixbNjIsMjgyLDI4N11dLFsi2KfZhNmF2LPYqti32YrYsSIsWzYzLDI4OCwy OTZdXSxbIiwiLFs2NCwyOTcsMjk4XV0sWyLZhtmK2LHYp9mGIixbNjUsMjk5LDMwNF1dLFsi2KfZ hNmD2LHYp9mH2YrYqSIsWzY2LDMwNSwzMTNdXSxbItiq2LnYqtmF2YQiLFs2NywzMTQsMzE5XV0s WyLZgdmJIixbNjgsMzIwLDMyMl1dLFsi2KfZhNi12K/ZiNixIixbNjksMzIzLDMyOV1dLFsiLCIs WzcwLDMzMCwzMzFdXSxbItit2YXZhSIsWzcxLDMzMiwzMzVdXSxbItmE2YgiLFs3MiwzMzYsMzM4 XV0sWyLYqti52YTZhdmI2YYiLFs3MywzMzksMzQ1XV0sWyIuIixbNzQsMzQ2LDM0N11dXV0sWyJh dGIiLFsic3JjIiwibmUiLCJtb3JwaCIsImRlY29yYXRlZCJdLFtbItmD2YQiLCIiLCLZg9mEIiwi 2YPZhCIsWzAsMCwyXV0sWyLZh9iw2KciLCIiLCLZh9iw2KciLCLZh9iw2KciLFsxLDMsNl1dLFsi 2KfZhNmD2LHZhyIsIiIsItin2YQjINmD2LHZhyIsItin2YTZg9ix2YciLFsyLDcsMTJdXSxbIiwi LCIiLCIsIiwiLCIsWzMsMTMsMTRdXSxbItmB2KfYpti2IiwiIiwi2YHYp9im2LYiLCLZgdin2KbY tiIsWzQsMTUsMTldXSxbItin2YTZg9ix2KfZh9mK2KkiLCIiLCLYp9mEIyDZg9ix2KfZh9mKICvY qSIsItin2YTZg9ix2KfZh9mK2KkiLFs1LDIwLDI4XV0sWyLYrdin2YTYqSIsIiIsItit2KfZhCAr 2KkiLCLYrdin2YTYqSIsWzYsMjksMzNdXSxbIti62KjZitipIiwiIiwi2LrYqNmKICvYqSIsIti6 2KjZitipIixbNywzNCwzOF1dLFsi2KrZhNmBIiwiIiwi2KojINmE2YEiLCLYqtmE2YEiLFs4LDM5 LDQyXV0sWyIr2YbYpyIsIiIsIivZhtinIiwiK9mG2KciLFs5LDQzLDQ2XV0sWyLZhdmGIiwiIiwi 2YXZhiIsItmF2YYiLFsxMCw0Nyw0OV1dLFsi2YPZhCIsIiIsItmD2YQiLCLZg9mEIixbMTEsNTAs NTJdXSxbItis2KfZhtioIiwiIiwi2KzYp9mG2KgiLCLYrNin2YbYqCIsWzEyLDUzLDU3XV0sWyIs IiwiIiwiLCIsIiwiLFsxMyw1OCw1OV1dLFsi2LnZhtivIiwiIiwi2LnZhtivIiwi2LnZhtivIixb MTQsNjAsNjNdXSxbIivZhdinIiwiIiwiK9mF2KciLCIr2YXYpyIsWzE1LDY0LDY3XV0sWyLZitiq 2YXZhti32YIiLCIiLCLZiiMg2KrZhdmG2LfZgiIsItmK2KrZhdmG2LfZgiIsWzE2LDY4LDc0XV0s WyLYp9mE2KjYudi2IiwiIiwi2KfZhCMg2KjYudi2Iiwi2KfZhNio2LnYtiIsWzE3LDc1LDgwXV0s WyLYqCMiLCIiLCLYqCMiLCLYqCMiLFsxOCw4MSw4M11dLFsi2KfZhNmD2LHYp9mH2YrYqSIsIiIs Itin2YQjINmD2LHYp9mH2YogK9ipIiwi2KfZhNmD2LHYp9mH2YrYqSIsWzE5LDg0LDkyXV0sWyIs IiwiIiwiLCIsIiwiLFsyMCw5Myw5NF1dLFsi2LnZhtivIiwiIiwi2LnZhtivIiwi2LnZhtivIixb MjEsOTUsOThdXSxbIivZhdinIiwiIiwiK9mF2KciLCIr2YXYpyIsWzIyLDk5LDEwMl1dLFsi2YrY udiq2YXZhCIsIiIsItmKIyDYudiq2YXZhCIsItmK2LnYqtmF2YQiLFsyMywxMDMsMTA4XV0sWyLY p9mE2KvYp9ixIiwiIiwi2KfZhCMg2KvYp9ixIiwi2KfZhNir2KfYsSIsWzI0LDEwOSwxMTRdXSxb ItmB2YoiLCIiLCLZgdmKIiwi2YHZiiIsWzI1LDExNSwxMTddXSxbItin2YTZhtmB2YjYsyIsIiIs Itin2YQjINmG2YHZiNizIiwi2KfZhNmG2YHZiNizIixbMjYsMTE4LDEyNF1dLFsiLCIsIiIsIiwi LCIsIixbMjcsMTI1LDEyNl1dLFsi2KrYtdmK2LEiLCIiLCLYqiMg2LXZitixIiwi2KrYtdmK2LEi LFsyOCwxMjcsMTMxXV0sWyLZgtmG2KfYqNmEIiwiIiwi2YLZhtin2KjZhCIsItmC2YbYp9io2YQi LFsyOSwxMzIsMTM3XV0sWyLYqNi02LHZitipIiwiIiwi2KjYtNix2YogK9ipIiwi2KjYtNix2YrY qSIsWzMwLDEzOCwxNDNdXSxbItiq2YXYtNmKIiwiIiwi2KrZhdi02YoiLCLYqtmF2LTZiiIsWzMx LDE0NCwxNDhdXSxbIti52YTZiiIsIiIsIti52YTZiiIsIti52YTZiiIsWzMyLDE0OSwxNTJdXSxb ItmC2K/ZhdmK2YYiLCIiLCLZgtiv2YUgK9mK2YYiLCLZgtiv2YXZitmGIixbMzMsMTUzLDE1OF1d LFsiLCIsIiIsIiwiLCIsIixbMzQsMTU5LDE2MF1dLFsi2KfZhiIsIiIsItin2YYiLCLYp9mGIixb MzUsMTYxLDE2M11dLFsi2LHYp9iqIiwiIiwi2LHYp9iqIiwi2LHYp9iqIixbMzYsMTY0LDE2N11d LFsi2YbYp9ix2KciLCIiLCLZhtin2LHYpyIsItmG2KfYsdinIixbMzcsMTY4LDE3Ml1dLFsi2KrY tdioIiwiIiwi2KojINi12KgiLCLYqti12KgiLFszOCwxNzMsMTc2XV0sWyLZhdmGIiwiIiwi2YXZ hiIsItmF2YYiLFszOSwxNzcsMTc5XV0sWyLZhtmB2YjYsyIsIiIsItmG2YHZiNizIiwi2YbZgdmI 2LMiLFs0MCwxODAsMTg0XV0sWyIr2YfYpyIsIiIsIivZh9inIiwiK9mH2KciLFs0MSwxODUsMTg4 XV0sWyLYqNmG2LLZitmG2KciLCIiLCLYqNmG2LLZitmG2KciLCLYqNmG2LLZitmG2KciLFs0Miwx ODksMTk1XV0sWyIsIiwiIiwiLCIsIiwiLFs0MywxOTYsMTk3XV0sWyLYp9mE2YPYsdin2YfZitip IiwiIiwi2KfZhCMg2YPYsdin2YfZiiAr2KkiLCLYp9mE2YPYsdin2YfZitipIixbNDQsMTk4LDIw Nl1dLFsi2K3Yp9mE2KkiLCIiLCLYrdin2YQgK9ipIiwi2K3Yp9mE2KkiLFs0NSwyMDcsMjExXV0s WyLZhdix2LbZitipIiwiIiwi2YXYsdi22YogK9ipIiwi2YXYsdi22YrYqSIsWzQ2LDIxMiwyMTdd XSxbItiq2LPYqtio2K8iLCIiLCLYqiMg2LPYqtio2K8iLCLYqtiz2KrYqNivIixbNDcsMjE4LDIy M11dLFsi2KgjIiwiIiwi2KgjIiwi2KgjIixbNDgsMjI0LDIyNl1dLFsi2KfZhNmI2LfZhiIsIiIs Itin2YQjINmI2LfZhiIsItin2YTZiNi32YYiLFs0OSwyMjcsMjMyXV0sWyIsIiwiIiwiLCIsIiwi LFs1MCwyMzMsMjM0XV0sWyLYqti52KjZitixIiwiIiwi2KrYudio2YrYsSIsItiq2LnYqNmK2LEi LFs1MSwyMzUsMjQwXV0sWyLZg9in2LEiLCIiLCLZg9in2LEiLCLZg9in2LEiLFs1MiwyNDEsMjQ0 XV0sWyIr2YciLCIiLCIr2YciLCIr2YciLFs1MywyNDUsMjQ3XV0sWyLYudmGIiwiIiwi2LnZhiIs Iti52YYiLFs1NCwyNDgsMjUwXV0sWyLYuti22KgiLCIiLCLYuti22KgiLCLYuti22KgiLFs1NSwy NTEsMjU0XV0sWyLZhdiz2KrYt9mK2LEiLCIiLCLZhdiz2KrYt9mK2LEiLCLZhdiz2KrYt9mK2LEi LFs1NiwyNTUsMjYxXV0sWyIuLiIsIiIsIi4uIiwiLi4iLFs1NywyNjIsMjY0XV0sWyLZhNinIiwi Iiwi2YTYpyIsItmE2KciLFs1OCwyNjUsMjY3XV0sWyLZitmB2LHZgiIsIiIsItmKIyDZgdix2YIi LCLZitmB2LHZgiIsWzU5LDI2OCwyNzJdXSxbItmD2KvZitix2KciLCIiLCLZg9ir2YrYsSAr2Kci LCLZg9ir2YrYsdinIixbNjAsMjczLDI3OF1dLFsi2LnZhiIsIiIsIti52YYiLCLYudmGIixbNjEs Mjc5LDI4MV1dLFsi2KfZhNi02LHYsSIsIiIsItin2YQjINi02LHYsSIsItin2YTYtNix2LEiLFs2 MiwyODIsMjg3XV0sWyLYp9mE2YXYs9iq2LfZitixIiwiIiwi2KfZhCMg2YXYs9iq2LfZitixIiwi 2KfZhNmF2LPYqti32YrYsSIsWzYzLDI4OCwyOTZdXSxbIiwiLCIiLCIsIiwiLCIsWzY0LDI5Nywy OThdXSxbItmG2YrYsdin2YYiLCIiLCLZhtmK2LHYp9mGIiwi2YbZitix2KfZhiIsWzY1LDI5OSwz MDRdXSxbItin2YTZg9ix2KfZh9mK2KkiLCIiLCLYp9mEIyDZg9ix2KfZh9mKICvYqSIsItin2YTZ g9ix2KfZh9mK2KkiLFs2NiwzMDUsMzEzXV0sWyLYqti52KrZhdmEIiwiIiwi2KojINi52KrZhdmE Iiwi2KrYudiq2YXZhCIsWzY3LDMxNCwzMTldXSxbItmB2YoiLCIiLCLZgdmKIiwi2YHZiiIsWzY4 LDMyMCwzMjJdXSxbItin2YTYtdiv2YjYsSIsIiIsItin2YQjINi12K/ZiNixIiwi2KfZhNi12K/Z iNixIixbNjksMzIzLDMyOV1dLFsiLCIsIiIsIiwiLCIsIixbNzAsMzMwLDMzMV1dLFsi2K3ZhdmF IiwiIiwi2K3ZhdmFIiwi2K3ZhdmFIixbNzEsMzMyLDMzNV1dLFsi2YTZiCIsIiIsItmE2YgiLCLZ hNmIIixbNzIsMzM2LDMzOF1dLFsi2KrYudmE2YXZiNmGIiwiIiwi2KrYudmE2YUgK9mI2YYiLCLY qti52YTZhdmI2YYiLFs3MywzMzksMzQ1XV0sWyIuIiwiIiwiLiIsIi4iLFs3NCwzNDYsMzQ3XV1d XSxbInRvayIsWyJ0b2tub3JtIl0sW1si2YPZhCIsWzAsLTEsLTFdXSxbItmH2LDYpyIsWzEsLTEs LTFdXSxbItin2YTZg9ix2YciLFsyLC0xLC0xXV0sWyIsIixbMywtMSwtMV1dLFsi2YHYp9im2LYi LFs0LC0xLC0xXV0sWyLYp9mE2YPYsdin2YfZitipIixbNSwtMSwtMV1dLFsi2K3Yp9mE2KkiLFs2 LC0xLC0xXV0sWyLYutio2YrYqSIsWzcsLTEsLTFdXSxbItiq2YTZgdmG2KciLFs4LC0xLC0xXV0s WyLZhdmGIixbOSwtMSwtMV1dLFsi2YPZhCIsWzEwLC0xLC0xXV0sWyLYrNin2YbYqCIsWzExLC0x LC0xXV0sWyIsIixbMTIsLTEsLTFdXSxbIti52YbYr9mF2KciLFsxMywtMSwtMV1dLFsi2YrYqtmF 2YbYt9mCIixbMTQsLTEsLTFdXSxbItin2YTYqNi52LYiLFsxNSwtMSwtMV1dLFsi2KjYp9mE2YPY sdin2YfZitipIixbMTYsLTEsLTFdXSxbIiwiLFsxNywtMSwtMV1dLFsi2LnZhtiv2YXYpyIsWzE4 LC0xLC0xXV0sWyLZiti52KrZhdmEIixbMTksLTEsLTFdXSxbItin2YTYq9in2LEiLFsyMCwtMSwt MV1dLFsi2YHZiiIsWzIxLC0xLC0xXV0sWyLYp9mE2YbZgdmI2LMiLFsyMiwtMSwtMV1dLFsiLCIs WzIzLC0xLC0xXV0sWyLYqti12YrYsSIsWzI0LC0xLC0xXV0sWyLZgtmG2KfYqNmEIixbMjUsLTEs LTFdXSxbItio2LTYsdmK2KkiLFsyNiwtMSwtMV1dLFsi2KrZhdi02YoiLFsyNywtMSwtMV1dLFsi 2LnZhNmKIixbMjgsLTEsLTFdXSxbItmC2K/ZhdmK2YYiLFsyOSwtMSwtMV1dLFsiLCIsWzMwLC0x LC0xXV0sWyLYp9mGIixbMzEsLTEsLTFdXSxbItix2KfYqiIsWzMyLC0xLC0xXV0sWyLZhtin2LHY pyIsWzMzLC0xLC0xXV0sWyLYqti12KgiLFszNCwtMSwtMV1dLFsi2YXZhiIsWzM1LC0xLC0xXV0s WyLZhtmB2YjYs9mH2KciLFszNiwtMSwtMV1dLFsi2KjZhtiy2YrZhtinIixbMzcsLTEsLTFdXSxb IiwiLFszOCwtMSwtMV1dLFsi2KfZhNmD2LHYp9mH2YrYqSIsWzM5LC0xLC0xXV0sWyLYrdin2YTY qSIsWzQwLC0xLC0xXV0sWyLZhdix2LbZitipIixbNDEsLTEsLTFdXSxbItiq2LPYqtio2K8iLFs0 MiwtMSwtMV1dLFsi2KjYp9mE2YjYt9mGIixbNDMsLTEsLTFdXSxbIiwiLFs0NCwtMSwtMV1dLFsi 2KrYudio2YrYsSIsWzQ1LC0xLC0xXV0sWyLZg9in2LHZhyIsWzQ2LC0xLC0xXV0sWyLYudmGIixb NDcsLTEsLTFdXSxbIti62LbYqCIsWzQ4LC0xLC0xXV0sWyLZhdiz2KrYt9mK2LEiLFs0OSwtMSwt MV1dLFsiLi4iLFs1MCwtMSwtMV1dLFsi2YTYpyIsWzUxLC0xLC0xXV0sWyLZitmB2LHZgiIsWzUy LC0xLC0xXV0sWyLZg9ir2YrYsdinIixbNTMsLTEsLTFdXSxbIti52YYiLFs1NCwtMSwtMV1dLFsi 2KfZhNi02LHYsSIsWzU1LC0xLC0xXV0sWyLYp9mE2YXYs9iq2LfZitixIixbNTYsLTEsLTFdXSxb IiwiLFs1NywtMSwtMV1dLFsi2YbZitix2KfZhiIsWzU4LC0xLC0xXV0sWyLYp9mE2YPYsdin2YfZ itipIixbNTksLTEsLTFdXSxbItiq2LnYqtmF2YQiLFs2MCwtMSwtMV1dLFsi2YHZiiIsWzYxLC0x LC0xXV0sWyLYp9mE2LXYr9mI2LEiLFs2MiwtMSwtMV1dLFsiLCIsWzYzLC0xLC0xXV0sWyLYrdmF 2YUiLFs2NCwtMSwtMV1dLFsi2YTZiCIsWzY1LC0xLC0xXV0sWyLYqti52YTZhdmI2YYiLFs2Niwt MSwtMV1dLFsiLiIsWzY3LC0xLC0xXV1dXSxbIm1vcnBoIixbImZpbiJdLFtbItmD2YQiLFswLC0x LC0xXV0sWyLZh9iw2KciLFsxLC0xLC0xXV0sWyLYp9mEIyDZg9ix2YciLFsyLC0xLC0xXV0sWyIs IixbMywtMSwtMV1dLFsi2YHYp9im2LYiLFs0LC0xLC0xXV0sWyLYp9mEIyDZg9ix2KfZh9mKICvY qSIsWzUsLTEsLTFdXSxbItit2KfZhCAr2KkiLFs2LC0xLC0xXV0sWyLYutio2YogK9ipIixbNywt MSwtMV1dLFsi2KojINmE2YEiLFs4LC0xLC0xXV0sWyIr2YbYpyIsWzksLTEsLTFdXSxbItmF2YYi LFsxMCwtMSwtMV1dLFsi2YPZhCIsWzExLC0xLC0xXV0sWyLYrNin2YbYqCIsWzEyLC0xLC0xXV0s WyIsIixbMTMsLTEsLTFdXSxbIti52YbYryIsWzE0LC0xLC0xXV0sWyIr2YXYpyIsWzE1LC0xLC0x XV0sWyLZiiMg2KrZhdmG2LfZgiIsWzE2LC0xLC0xXV0sWyLYp9mEIyDYqNi52LYiLFsxNywtMSwt MV1dLFsi2KgjIixbMTgsLTEsLTFdXSxbItin2YQjINmD2LHYp9mH2YogK9ipIixbMTksLTEsLTFd XSxbIiwiLFsyMCwtMSwtMV1dLFsi2LnZhtivIixbMjEsLTEsLTFdXSxbIivZhdinIixbMjIsLTEs LTFdXSxbItmKIyDYudiq2YXZhCIsWzIzLC0xLC0xXV0sWyLYp9mEIyDYq9in2LEiLFsyNCwtMSwt MV1dLFsi2YHZiiIsWzI1LC0xLC0xXV0sWyLYp9mEIyDZhtmB2YjYsyIsWzI2LC0xLC0xXV0sWyIs IixbMjcsLTEsLTFdXSxbItiqIyDYtdmK2LEiLFsyOCwtMSwtMV1dLFsi2YLZhtin2KjZhCIsWzI5 LC0xLC0xXV0sWyLYqNi02LHZiiAr2KkiLFszMCwtMSwtMV1dLFsi2KrZhdi02YoiLFszMSwtMSwt MV1dLFsi2LnZhNmKIixbMzIsLTEsLTFdXSxbItmC2K/ZhSAr2YrZhiIsWzMzLC0xLC0xXV0sWyIs IixbMzQsLTEsLTFdXSxbItin2YYiLFszNSwtMSwtMV1dLFsi2LHYp9iqIixbMzYsLTEsLTFdXSxb ItmG2KfYsdinIixbMzcsLTEsLTFdXSxbItiqIyDYtdioIixbMzgsLTEsLTFdXSxbItmF2YYiLFsz OSwtMSwtMV1dLFsi2YbZgdmI2LMiLFs0MCwtMSwtMV1dLFsiK9mH2KciLFs0MSwtMSwtMV1dLFsi 2KjZhtiy2YrZhtinIixbNDIsLTEsLTFdXSxbIiwiLFs0MywtMSwtMV1dLFsi2KfZhCMg2YPYsdin 2YfZiiAr2KkiLFs0NCwtMSwtMV1dLFsi2K3Yp9mEICvYqSIsWzQ1LC0xLC0xXV0sWyLZhdix2LbZ iiAr2KkiLFs0NiwtMSwtMV1dLFsi2KojINiz2KrYqNivIixbNDcsLTEsLTFdXSxbItioIyIsWzQ4 LC0xLC0xXV0sWyLYp9mEIyDZiNi32YYiLFs0OSwtMSwtMV1dLFsiLCIsWzUwLC0xLC0xXV0sWyLY qti52KjZitixIixbNTEsLTEsLTFdXSxbItmD2KfYsSIsWzUyLC0xLC0xXV0sWyIr2YciLFs1Mywt MSwtMV1dLFsi2LnZhiIsWzU0LC0xLC0xXV0sWyLYuti22KgiLFs1NSwtMSwtMV1dLFsi2YXYs9iq 2LfZitixIixbNTYsLTEsLTFdXSxbIi4uIixbNTcsLTEsLTFdXSxbItmE2KciLFs1OCwtMSwtMV1d LFsi2YojINmB2LHZgiIsWzU5LC0xLC0xXV0sWyLZg9ir2YrYsSAr2KciLFs2MCwtMSwtMV1dLFsi 2LnZhiIsWzYxLC0xLC0xXV0sWyLYp9mEIyDYtNix2LEiLFs2MiwtMSwtMV1dLFsi2KfZhCMg2YXY s9iq2LfZitixIixbNjMsLTEsLTFdXSxbIiwiLFs2NCwtMSwtMV1dLFsi2YbZitix2KfZhiIsWzY1 LC0xLC0xXV0sWyLYp9mEIyDZg9ix2KfZh9mKICvYqSIsWzY2LC0xLC0xXV0sWyLYqiMg2LnYqtmF 2YQiLFs2NywtMSwtMV1dLFsi2YHZiiIsWzY4LC0xLC0xXV0sWyLYp9mEIyDYtdiv2YjYsSIsWzY5 LC0xLC0xXV0sWyIsIixbNzAsLTEsLTFdXSxbItit2YXZhSIsWzcxLC0xLC0xXV0sWyLZhNmIIixb NzIsLTEsLTFdXSxbItiq2LnZhNmFICvZiNmGIixbNzMsLTEsLTFdXSxbIi4iLFs3NCwtMSwtMV1d XV0sWyJyYXciLFsiYWxpZ24iXSxbWyIwIixbMCwwLDJdXSxbIjAiLFswLDMsNl1dLFsiMCIsWzAs NywxMl1dLFsiMjA0OCIsWzAsMTIsMTNdXSxbIjAiLFswLDE0LDE4XV0sWyIwIixbMCwxOSwyN11d LFsiMCIsWzAsMjgsMzJdXSxbIjAiLFswLDMzLDM3XV0sWyIwIixbMCwzOCw0MV1dLFsiNTEyIixb MCw0MSw0M11dLFsiMCIsWzAsNDQsNDZdXSxbIjAiLFswLDQ3LDQ5XV0sWyIwIixbMCw1MCw1NF1d LFsiMjA0OCIsWzAsNTQsNTVdXSxbIjAiLFswLDU2LDU5XV0sWyI1MTIiLFswLDU5LDYxXV0sWyIw IixbMCw2Miw2OF1dLFsiMCIsWzAsNjksNzRdXSxbIjI1NiIsWzAsNzUsNzZdXSxbIjAiLFswLDc2 LDg0XV0sWyIyMDQ4IixbMCw4NCw4NV1dLFsiMCIsWzAsODYsODldXSxbIjUxMiIsWzAsODksOTFd XSxbIjAiLFswLDkyLDk3XV0sWyIwIixbMCw5OCwxMDNdXSxbIjAiLFswLDEwNCwxMDZdXSxbIjAi LFswLDEwNywxMTNdXSxbIjIwNDgiLFswLDExMywxMTRdXSxbIjAiLFswLDExNSwxMTldXSxbIjAi LFswLDEyMCwxMjVdXSxbIjAiLFswLDEyNiwxMzFdXSxbIjAiLFswLDEzMiwxMzZdXSxbIjAiLFsw LDEzNywxNDBdXSxbIjAiLFswLDE0MSwxNDZdXSxbIjIwNDgiLFswLDE0NiwxNDddXSxbIjAiLFsw LDE0OCwxNTBdXSxbIjAiLFswLDE1MSwxNTRdXSxbIjAiLFswLDE1NSwxNTldXSxbIjAiLFswLDE2 MCwxNjNdXSxbIjAiLFswLDE2NCwxNjZdXSxbIjAiLFswLDE2NywxNzFdXSxbIjUxMiIsWzAsMTcx LDE3M11dLFsiMCIsWzAsMTc0LDE4MF1dLFsiMjA0OCIsWzAsMTgwLDE4MV1dLFsiMCIsWzAsMTgy LDE5MF1dLFsiMCIsWzAsMTkxLDE5NV1dLFsiMCIsWzAsMTk2LDIwMV1dLFsiMCIsWzAsMjAyLDIw N11dLFsiMjU2IixbMCwyMDgsMjA5XV0sWyIwIixbMCwyMDksMjE0XV0sWyIyMDQ4IixbMCwyMTQs MjE1XV0sWyIwIixbMCwyMTYsMjIxXV0sWyIwIixbMCwyMjIsMjI1XV0sWyI1MTIiLFswLDIyNSwy MjZdXSxbIjAiLFswLDIyNywyMjldXSxbIjAiLFswLDIzMCwyMzNdXSxbIjAiLFswLDIzNCwyNDBd XSxbIjAiLFswLDI0MCwyNDJdXSxbIjAiLFswLDI0MywyNDVdXSxbIjAiLFswLDI0NiwyNTBdXSxb IjAiLFswLDI1MSwyNTZdXSxbIjAiLFswLDI1NywyNTldXSxbIjAiLFswLDI2MCwyNjVdXSxbIjAi LFswLDI2NiwyNzRdXSxbIjIwNDgiLFswLDI3NCwyNzVdXSxbIjAiLFswLDI3NiwyODFdXSxbIjAi LFswLDI4MiwyOTBdXSxbIjAiLFswLDI5MSwyOTZdXSxbIjAiLFswLDI5NywyOTldXSxbIjAiLFsw LDMwMCwzMDZdXSxbIjIwNDgiLFswLDMwNiwzMDddXSxbIjAiLFswLDMwOCwzMTFdXSxbIjAiLFsw LDMxMiwzMTRdXSxbIjAiLFswLDMxNSwzMjFdXSxbIjYxNDQiLFswLDMyMSwzMjJdXV1dXQ0KDQoN ClRoYW5rcw0KSmVycnkNCg0KDQoNCkluIEdOVSBFbWFjcyAyNC4zLjEgKHg4Nl82NC11bmtub3du LWxpbnV4LWdudSwgR1RLKyBWZXJzaW9uIDIuMTguOSkNCiBvZiAyMDEzLTA4LTEzIG9uIHNtYXVn LndhdHNvbi5pYm0uY29tDQpXaW5kb3dpbmcgc3lzdGVtIGRpc3RyaWJ1dG9yIGBDZW50T1MnLCB2 ZXJzaW9uIDExLjAuMTEzMDAwMDANClN5c3RlbSBEZXNjcmlwdGlvbjoJQ2VudE9TIHJlbGVhc2Ug Ni40IChGaW5hbCkNCg0KQ29uZmlndXJlZCB1c2luZzoNCiBgY29uZmlndXJlICctLXByZWZpeD0v aWttLzc3L3dzJyAnLS13aXRoLXgtdG9vbGtpdD1ndGsyJycNCg0KSW1wb3J0YW50IHNldHRpbmdz Og0KICB2YWx1ZSBvZiAkTEFORzogZW5fVVMuVVRGLTgNCiAgdmFsdWUgb2YgJFhNT0RJRklFUlM6 IEBpbT1ub25lDQogIGxvY2FsZS1jb2Rpbmctc3lzdGVtOiB1dGYtOC11bml4DQogIGRlZmF1bHQg ZW5hYmxlLW11bHRpYnl0ZS1jaGFyYWN0ZXJzOiB0DQoNCk1ham9yIG1vZGU6IEZ1bmRhbWVudGFs DQoNCk1pbm9yIG1vZGVzIGluIGVmZmVjdDoNCiAgc2hlbGwtZGlydHJhY2stbW9kZTogdA0KICBk aWZmLWF1dG8tcmVmaW5lLW1vZGU6IHQNCiAgaXN3aXRjaGItbW9kZTogdA0KICBtb3VzZS13aGVl bC1tb2RlOiB0DQogIG1lbnUtYmFyLW1vZGU6IHQNCiAgZmlsZS1uYW1lLXNoYWRvdy1tb2RlOiB0 DQogIGdsb2JhbC1mb250LWxvY2stbW9kZTogdA0KICBmb250LWxvY2stbW9kZTogdA0KICBhdXRv LWNvbXBvc2l0aW9uLW1vZGU6IHQNCiAgYXV0by1lbmNyeXB0aW9uLW1vZGU6IHQNCiAgYXV0by1j b21wcmVzc2lvbi1tb2RlOiB0DQogIGxpbmUtbnVtYmVyLW1vZGU6IHQNCiAgdHJhbnNpZW50LW1h cmstbW9kZTogdA0KDQpSZWNlbnQgaW5wdXQ6DQpDLWcgQy1nIEMtaCB2IGIgaSBkIGkgPHRhYj4g PHRhYj4gQy1nIEMtaCBpIHEgQy1oIHYgDQpiIGkgZCBpIC0gZCBpIDx0YWI+IDx0YWI+IGkgPHRh Yj4gPHJldHVybj4gTS14IHMgZSANCnQgU1BDIHYgYSA8dGFiPiA8cmV0dXJuPiBiIGkgZCBpIC0g ZCBpIHMgcCBsIGEgeSAtIA0KciBlIG8gciA8dGFiPiBkIGUgciBpIG4gZyA8cmV0dXJuPiBDLWcg Qy1nIEMtZyBDLWcgDQpNLTogTS0oIDx1cD4gQy1lIDxDLWxlZnQ+IDxDLWxlZnQ+IDxDLXJpZ2h0 PiBpIG4gZyANCjxyZXR1cm4+IEMteCAxIDxDLXJpZ2h0PiA8Qy1yaWdodD4gPEMtcmlnaHQ+IDxD LXJpZ2h0PiANCjxDLXJpZ2h0PiA8Qy1yaWdodD4gPEMtcmlnaHQ+IDxDLXJpZ2h0PiA8Qy1yaWdo dD4gPEMtcmlnaHQ+IA0KPEMtcmlnaHQ+IDxDLXJpZ2h0PiA8Qy1yaWdodD4gPEMtcmlnaHQ+IDxD LXJpZ2h0PiA8Qy1yaWdodD4gDQo8Qy1yaWdodD4gPEMtcmlnaHQ+IDxDLXJpZ2h0PiA8Qy1yaWdo dD4gPEMtcmlnaHQ+IDxDLXJpZ2h0PiANCjxDLXJpZ2h0PiA8Qy1yaWdodD4gPEMtcmlnaHQ+IDxD LXJpZ2h0PiBDLWUgPEMtbGVmdD4gDQo8Qy1sZWZ0PiA8Qy1sZWZ0PiA8Qy1sZWZ0PiA8Qy1sZWZ0 PiA8Qy1sZWZ0PiA8dXA+IDx1cD4gDQo8dXA+IDx1cD4gPHVwPiA8dXA+IDx1cD4gPHVwPiA8dXA+ IDx1cD4gPHVwPiA8dXA+IDx1cD4gDQo8dXA+IDx1cD4gPHVwPiA8dXA+IDx1cD4gPHVwPiA8dXA+ IDx1cD4gPHVwPiA8dXA+IDx1cD4gDQo8dXA+IDx1cD4gPHVwPiA8dXA+IDx1cD4gPHVwPiA8dXA+ IDx1cD4gPHVwPiA8dXA+IDx1cD4gDQo8dXA+IDx1cD4gPHVwPiA8dXA+IDx1cD4gPHVwPiA8dXA+ IDx1cD4gPHVwPiA8dXA+IDx1cD4gDQo8dXA+IDx1cD4gPHVwPiA8dXA+IDx1cD4gPHVwPiA8dXA+ IDx1cD4gPHVwPiA8dXA+IDx1cD4gDQo8dXA+IDx1cD4gPHVwPiA8dXA+IDx1cD4gPHVwPiA8dXA+ IDx1cD4gPHVwPiA8dXA+IDx1cD4gDQo8dXA+IDx1cD4gPHVwPiA8dXA+IDx1cD4gPHVwPiA8dXA+ IDx1cD4gPHVwPiA8dXA+IDx1cD4gDQo8dXA+IDx1cD4gPHVwPiA8dXA+IDxkb3duPiA8ZG93bj4g PHVwPiA8dXA+IDx1cD4gPGRvd24+IA0KPGRvd24+IDxkb3duPiA8ZG93bj4gPGRvd24+IDxkb3du PiA8ZG93bj4gPGRvd24+IDxkb3duPiANCjxkb3duPiA8ZG93bj4gPGRvd24+IDxkb3duPiA8ZG93 bj4gPGRvd24+IDxkb3duPiA8ZG93bj4gDQo8ZG93bj4gPGRvd24+IDxkb3duPiA8ZG93bj4gPGRv d24+IDxkb3duPiA8ZG93bj4gPGRvd24+IA0KPGRvd24+IDxkb3duPiA8ZG93bj4gPGRvd24+IDxk b3duPiA8ZG93bj4gPGRvd24+IDxkb3duPiANCjxkb3duPiA8ZG93bj4gPGRvd24+IDxkb3duPiA8 ZG93bj4gPGRvd24+IDxkb3duPiA8ZG93bj4gDQo8ZG93bj4gPGRvd24+IDxkb3duPiA8ZG93bj4g PGRvd24+IDxkb3duPiA8ZG93bj4gPGRvd24+IA0KPGRvd24+IDxkb3duPiA8ZG93bj4gPGRvd24+ IDxkb3duPiA8ZG93bj4gPGRvd24+IDxkb3duPiANCjxkb3duPiA8ZG93bj4gPGRvd24+IDxkb3du PiA8ZG93bj4gPGRvd24+IDxkb3duPiA8ZG93bj4gDQo8ZG93bj4gPGRvd24+IDxkb3duPiA8ZG93 bj4gPGRvd24+IDxkb3duPiA8ZG93bj4gPGRvd24+IA0KPGRvd24+IDxkb3duPiA8dXA+IDx1cD4g PHVwPiA8dXA+IDx1cD4gQy1lIEMteCA9IE0teCANCnIgZSBwIG8gciB0IFNQQyBtIGUgPHRhYj4g PGJhY2tzcGFjZT4gPGJhY2tzcGFjZT4gZSANCm0gPHRhYj4gPHJldHVybj4NCg0KUmVjZW50IG1l c3NhZ2VzOg0KTWFyayBzZXQgWzIgdGltZXNdDQpRdWl0IFs1IHRpbWVzXQ0KTWFraW5nIGNvbXBs ZXRpb24gbGlzdC4uLg0KUXVpdA0KTWFraW5nIGNvbXBsZXRpb24gbGlzdC4uLg0KVHlwZSBDLXgg MSB0byBkZWxldGUgdGhlIGhlbHAgd2luZG93Lg0KUXVpdCBbNCB0aW1lc10NCm5pbA0KYnl0ZS1j b2RlOiBCZWdpbm5pbmcgb2YgYnVmZmVyIFsxMCB0aW1lc10NCkNoYXI6IEMtaiAoMTAsICNvMTIs ICN4YSkgcG9pbnQ9MTQ1NzIgb2YgNjA1MTkwMCAoMCUpIGNvbHVtbj0xNDU3MQ0KDQpMb2FkLXBh dGggc2hhZG93czoNCk5vbmUgZm91bmQuDQoNCkZlYXR1cmVzOg0KKHNoYWRvdyBzb3J0IG1haWwt ZXh0ciBlbWFjc2J1ZyBtZXNzYWdlIGNsLW1hY3MgZ3YgZm9ybWF0LXNwZWMgcmZjODIyDQptbWwg bW1sLXNlYyBtbS1kZWNvZGUgbW0tYm9kaWVzIG1tLWVuY29kZSBtYWlsLXBhcnNlIHJmYzIyMzEg bWFpbGFiYnJldg0KZ21tLXV0aWxzIG1haWxoZWFkZXIgc2VuZG1haWwgcmZjMjA0NyByZmMyMDQ1 IGlldGYtZHJ1bXMgbWFpbC11dGlscw0Kc2hlbGwgcGNvbXBsZXRlIGdyZXAgY29tcGlsZSBtdWxl LXV0aWwgY2FsLW1vdmUgY2FsLW1lbnUgY2FsZW5kYXINCmNhbC1sb2FkZGVmcyBqcyBqc29uIGlt ZW51IHRoaW5nYXRwdCBlZGlmZi1tZXJnIGVkaWZmLWRpZmYgZWRpZmYtd2luZA0KZWRpZmYtaGVs cCBlZGlmZi11dGlsIGVkaWZmLW11bHQgZWRpZmYtaW5pdCBlZGlmZiBmZmFwIHVybC1wYXJzZQ0K YXV0aC1zb3VyY2UgZWllaW8gYnl0ZS1vcHQgYnl0ZWNvbXAgYnl0ZS1jb21waWxlIGNjb252IGdu dXMtdXRpbCBtbS11dGlsDQptYWlsLXByc3ZyIHBhc3N3b3JkLWNhY2hlIHVybC12YXJzIHRhYmlm eSBtYW4gbG9nLWVkaXQgdmMtY3ZzIHZjLXJjcw0KdmMtZGlyIGV3b2MgZGlmZi1tb2RlIGFkZC1s b2cgbG9nLXZpZXcgZWFzeS1tbW9kZSBwY3ZzLXV0aWwgdmMgcmVjdA0KZGFiYnJldiBtaXNlYXJj aCBtdWx0aS1pc2VhcmNoIHB5dGhvbiByeCBjb21pbnQgcmluZyBhbnNpLWNvbG9yDQpoZWxwLW1v ZGUgaXNvLXRyYW5zbCBpbmZvIGFyYy1tb2RlIGFyY2hpdmUtbW9kZSBkaXJlZC1hdXggbWFrZS1t b2RlDQpjYy1sYW5ncyBjbCBjYy1tb2RlIGNjLWZvbnRzIGNjLWd1ZXNzIGNjLW1lbnVzIGNjLWNt ZHMgY2Mtc3R5bGVzDQpjYy1hbGlnbiBjYy1lbmdpbmUgY2MtdmFycyBjYy1kZWZzIHNoLXNjcmlw dCBzbWllIGV4ZWN1dGFibGUgbnJvZmYtbW9kZQ0KbnhtbC11Y2hubSBybmcteHNkIHhzZC1yZWdl eHAgcm5nLWNtcGN0IHJuZy1ueG1sIHJuZy12YWxpZCBybmctbG9jDQpybmctdXJpIHJuZy1wYXJz ZSBueG1sLXBhcnNlIHJuZy1tYXRjaCBybmctZHQgcm5nLXV0aWwgcm5nLXB0dHJuIG54bWwtbnMN CmVhc3ltZW51IG54bWwtbW9kZSBueG1sLW91dGxuIG54bWwtcmFwIG54bWwtdXRpbCBueG1sLWds eXBoIG54bWwtZW5jDQp4bWx0b2sgc2dtbC1tb2RlIHBlcmwtbW9kZSB2Yy1kaXNwYXRjaGVyIHZj LXN2biBjb25mLW1vZGUgZGlyZWQgZGVza3RvcA0KamthLWNvbXByIHNhdmVwbGFjZSB1bmlxdWlm eSBhZHZpY2UgaGVscC1mbnMgY2wtbGliIGFkdmljZS1wcmVsb2FkDQppc3dpdGNoYiB0aW1lLWRh dGUgdG9vbHRpcCBlZGlmZi1ob29rIHZjLWhvb2tzIGxpc3AtZmxvYXQtdHlwZSBtd2hlZWwNCngt d2luIHgtZG5kIHRvb2wtYmFyIGRuZCBmb250c2V0IGltYWdlIHJlZ2V4cC1vcHQgZnJpbmdlIHRh YnVsYXRlZC1saXN0DQpuZXdjb21tZW50IGxpc3AtbW9kZSByZWdpc3RlciBwYWdlIG1lbnUtYmFy IHJmbi1lc2hhZG93IHRpbWVyIHNlbGVjdA0Kc2Nyb2xsLWJhciBtb3VzZSBqaXQtbG9jayBmb250 LWxvY2sgc3ludGF4IGZhY2VtZW51IGZvbnQtY29yZSBmcmFtZSBjaGFtDQpnZW9yZ2lhbiB1dGYt OC1sYW5nIG1pc2MtbGFuZyB2aWV0bmFtZXNlIHRpYmV0YW4gdGhhaSB0YWktdmlldCBsYW8NCmtv cmVhbiBqYXBhbmVzZSBoZWJyZXcgZ3JlZWsgcm9tYW5pYW4gc2xvdmFrIGN6ZWNoIGV1cm9wZWFu IGV0aGlvcGljDQppbmRpYW4gY3lyaWxsaWMgY2hpbmVzZSBjYXNlLXRhYmxlIGVwYS1ob29rIGpr YS1jbXByLWhvb2sgaGVscCBzaW1wbGUNCmFiYnJldiBtaW5pYnVmZmVyIGxvYWRkZWZzIGJ1dHRv biBmYWNlcyBjdXMtZmFjZSBtYWNyb2V4cCBmaWxlcw0KdGV4dC1wcm9wZXJ0aWVzIG92ZXJsYXkg c2hhMSBtZDUgYmFzZTY0IGZvcm1hdCBlbnYgY29kZS1wYWdlcyBtdWxlDQpjdXN0b20gd2lkZ2V0 IGhhc2h0YWJsZS1wcmludC1yZWFkYWJsZSBiYWNrcXVvdGUgbWFrZS1uZXR3b3JrLXByb2Nlc3MN CmRidXNiaW5kIGR5bmFtaWMtc2V0dGluZyBzeXN0ZW0tZm9udC1zZXR0aW5nIGZvbnQtcmVuZGVy LXNldHRpbmcNCm1vdmUtdG9vbGJhciBndGsgeC10b29sa2l0IHggbXVsdGktdHR5IGVtYWNzKQ0K From debbugs-submit-bounces@debbugs.gnu.org Tue Oct 08 02:43:03 2013 Received: (at 15555) by debbugs.gnu.org; 8 Oct 2013 06:43:04 +0000 Received: from localhost ([127.0.0.1]:33764 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VTR0Y-0002ba-Ls for submit@debbugs.gnu.org; Tue, 08 Oct 2013 02:43:03 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]:53838) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VTR0V-0002b6-D4 for 15555@debbugs.gnu.org; Tue, 08 Oct 2013 02:43:01 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MUC005007TJOX00@a-mtaout20.012.net.il> for 15555@debbugs.gnu.org; Tue, 08 Oct 2013 09:42:55 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MUC005IK7ZJDG80@a-mtaout20.012.net.il>; Tue, 08 Oct 2013 09:42:55 +0300 (IDT) Date: Tue, 08 Oct 2013 09:42:53 +0300 From: Eli Zaretskii Subject: Re: bug#15555: 24.3; Bidirectional display very slow with long lines In-reply-to: X-012-Sender: halo1@inter.net.il To: Jerome L Quinn Message-id: <83wqlo461e.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8BIT References: X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 15555 Cc: 15555@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Jerome L Quinn > Date: Mon, 7 Oct 2013 16:05:42 -0400 > > If I have a buffer with a very long line (14000 chars) with a mix of > ASCII and Arabic text, emacs gets painfully slow when point is further > along the line. Emacs is in general painfully slow with such long lines, even if there are only ASCII characters there. Presence of Arabic characters makes it slower, but it is unbearably slow even before that. This is a known deficiency of the Emacs display engine. This is bug #13675. > It looks like there's an N^2 algorithm dependent on the column of > point. No, there are no N² algorithms. However, for many display operations, Emacs needs to go to the beginning of the previous _physical_ line, and then go forward to the place it needs to redisplay. With very long lines, this takes a lot of time. If your data files don't include empty lines, there's perhaps another source of slowdown, which _is_ peculiar to bidirectional display: Emacs needs to find the beginning of the current paragraph to determine its "base direction". To see if this is your problem, try setting bidi-paragraph-direction to either left-to-right or right-to-left, depending on whether most of the text should be read left to right or right to left. > We encounter this kind of data in our work looking at generated > files. The only solution at the moment is to disable bidirectional > reordering. With 14 thousand characters per line, Emacs is slow even without reordering. Again, this is an existing bug. Disabling reordering is probably not a very good thing when you work with Arabic text. > There are also problems with the display. If you search for the following: > > 74,346,347 > > my display looks like: > > ... ,[["74,346,347],".",".","","."], ... > > Whereas it should display: > > ... ,[".","",".",".",[74,346,347]]]], ... > > Note that the first " is misplaced, even if you accept that the rest > should be reversed. This is what the Unicode Bidirectional Algorithm mandates, since " is a "weak" character, i.e. it gets its directionality from the surrounding text, and because your paragraph has the left-to-right base direction (because it begins with strong L2R character). Perhaps you should set bidi-paragraph-direction to right-to-left, as your text is predominantly Arabic. So I see no bug here wrt the display order. As for slow redisplay with very long lines, that is an existing bug report. From debbugs-submit-bounces@debbugs.gnu.org Tue Oct 08 11:40:08 2013 Received: (at 15555) by debbugs.gnu.org; 8 Oct 2013 15:40:08 +0000 Received: from localhost ([127.0.0.1]:35083 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VTZOI-0008Rf-Qf for submit@debbugs.gnu.org; Tue, 08 Oct 2013 11:40:07 -0400 Received: from e9.ny.us.ibm.com ([32.97.182.139]:41087) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VTZOD-0008R7-G1 for 15555@debbugs.gnu.org; Tue, 08 Oct 2013 11:40:02 -0400 Received: from /spool/local by e9.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for <15555@debbugs.gnu.org> from ; Tue, 8 Oct 2013 11:40:00 -0400 Received: from d01dlp02.pok.ibm.com (9.56.250.167) by e9.ny.us.ibm.com (192.168.1.109) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 8 Oct 2013 11:40:00 -0400 Received: from b01cxnp23032.gho.pok.ibm.com (b01cxnp23032.gho.pok.ibm.com [9.57.198.27]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 8380E6E803F for <15555@debbugs.gnu.org>; Tue, 8 Oct 2013 11:39:58 -0400 (EDT) Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by b01cxnp23032.gho.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r98FdxEt51183774 for <15555@debbugs.gnu.org>; Tue, 8 Oct 2013 15:39:59 GMT Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r98Fdxtj023411 for <15555@debbugs.gnu.org>; Tue, 8 Oct 2013 11:39:59 -0400 Received: from d01ml605.pok.ibm.com (d01ml605.pok.ibm.com [9.63.8.148]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id r98FdxNN023406; Tue, 8 Oct 2013 11:39:59 -0400 In-Reply-To: <83wqlo461e.fsf@gnu.org> References: <83wqlo461e.fsf@gnu.org> Subject: Re: bug#15555: 24.3; Bidirectional display very slow with long lines X-KeepSent: 2B55B1F5:54EA9C4F-85257BFE:0053238D; type=4; name=$KeepSent To: Eli Zaretskii X-Mailer: IBM Notes Release 9.0 March 08, 2013 Message-ID: From: Jerome L Quinn Date: Tue, 8 Oct 2013 11:39:58 -0400 X-MIMETrack: Serialize by Router on D01ML605/01/M/IBM(Release 9.0IF2 |July 03, 2013) at 10/08/2013 11:39:59 AM MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBF16DDFC0A51D8f9e8a93df938690918c0ABBF16DDFC0A51D" Content-Disposition: inline X-TM-AS-MML: No X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13100815-7182-0000-0000-000008AA68C2 X-Spam-Score: -5.3 (-----) X-Debbugs-Envelope-To: 15555 Cc: 15555@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.3 (-----) --0__=0ABBF16DDFC0A51D8f9e8a93df938690918c0ABBF16DDFC0A51D Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable Eli Zaretskii wrote on 10/08/2013 02:42:53 AM: > From: Eli Zaretskii > To: Jerome L Quinn/Watson/IBM@IBMUS > Cc: 15555@debbugs.gnu.org > Date: 10/08/2013 02:43 AM > Subject: Re: bug#15555: 24.3; Bidirectional display very slow with lo= ng lines > > > From: Jerome L Quinn > > Date: Mon, 7 Oct 2013 16:05:42 -0400 > > > > If I have a buffer with a very long line (14000 chars) with a mix o= f > > ASCII and Arabic text, emacs gets painfully slow when point is furt= her > > along the line. > > Emacs is in general painfully slow with such long lines, even if ther= e > are only ASCII characters there. Presence of Arabic characters makes= > it slower, but it is unbearably slow even before that. This is a > known deficiency of the Emacs display engine. This is bug #13675. Hi Eli, I'm not sure it is the same bug. When I disable the bidi reordering variable, navigation speed becomes reasonable, even with the very long line lengt= h. I'm on a very fast machine, so #13675 may not be impacting me that badl= y. When bidi reordering is enabled, it is multiple seconds to move the cur= sor up and down, which is unusable. > > It looks like there's an N^2 algorithm dependent on the column of > > point. > > No, there are no N=B2 algorithms. However, for many display operatio= ns, > Emacs needs to go to the beginning of the previous _physical_ line, > and then go forward to the place it needs to redisplay. With very > long lines, this takes a lot of time. > > If your data files don't include empty lines, there's perhaps another= > source of slowdown, which _is_ peculiar to bidirectional display: > Emacs needs to find the beginning of the current paragraph to > determine its "base direction". To see if this is your problem, try > setting bidi-paragraph-direction to either left-to-right or > right-to-left, depending on whether most of the text should be read > left to right or right to left. Setting bidi-paragraph-direction to right-to-left improves the situatio= n some but I'd still call it unusable in this situation. Disabling reordering= makes emacs as responsive as I'd expect, comparable to emacs23. OK, I played with it a bit more. I think the issue is exacerbated by splitting the frame into 2 side-by-side windows. Try this: Expand emacs to fill the screen. For me this is 194x65. Create a new buffer with just the text I included in the bug report. C-x 3 Put something else in the left window and go the right window. Page down several times. The last page down I find takes 5-8 seconds repeatedly. I don't see as bad behavior when the text is in the left buffer or if I= have only 1 window. And disabling bidi reordering completely eliminates the bad behavior. Thanks Jerry= --0__=0ABBF16DDFC0A51D8f9e8a93df938690918c0ABBF16DDFC0A51D Content-type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-transfer-encoding: quoted-printable

Eli Zaretskii <eliz@gnu.org> wrote on 10/= 08/2013 02:42:53 AM:

> From: Eli Zaretskii <eliz@gnu.org>
> To: Jerome L Quinn/Watson/IBM@IBMUS
> Cc: 15555@debbugs.gnu.org
> Date: 10/08/2013 02:43 AM
> Subject: Re: bug#15555: 24.3; Bidirectional d= isplay very slow with long lines
>
> > From: Jerome L Quinn <jlquinn@us.ibm.com>
> > Date: Mon, 7 Oct 2013 16:05:42 -0400
> >
> > If I have a buffer with a very long line (14000 chars) with a= mix of
> > ASCII and Arabic text, emacs gets painfully slow when point i= s further
> > along the line.
>
> Emacs is in general painfully slow with such long lines, even if t= here
> are only ASCII characters there.  Presence of Arabic characte= rs makes
> it slower, but it is unbearably slow even before that.  This = is a
> known deficiency of the Emacs display engine.  This is bug #1= 3675.

Hi Eli,

I'm not sure it is the same bug.  When I disa= ble the bidi reordering variable,
navigation speed becomes reasonable, even with the= very long line length.
I'm on a very fast machine, so #13675 may not be i= mpacting me that badly.

When bidi reordering is enabled, it is multiple se= conds to move the cursor up
and down, which is unusable.


> > It looks like there's an N^2 algorithm dependent on the colum= n of
> > point.
>
> No, there are no N=B2 algorithms.  However, for many display = operations,
> Emacs needs to go to the beginning of the previous _physical_ line= ,
> and then go forward to the place it needs to redisplay.  With= very
> long lines, this takes a lot of time.
>
> If your data files don't include empty lines, there's perhaps anot= her
> source of slowdown, which _is_ peculiar to bidirectional display:<= br> > Emacs needs to find the beginning of the current paragraph to
> determine its "base direction".  To see if this is = your problem, try
> setting bidi-paragraph-direction to either left-to-right or
> right-to-left, depending on whether most of the text should be rea= d
> left to right or right to left.

Setting bidi-paragraph-direction to right-to-left = improves the situation some
but I'd still call it unusable in this situation. =  Disabling reordering makes
emacs as responsive as I'd expect, comparable to e= macs23.

OK, I played with it a bit more.  I think the= issue is exacerbated by splitting
the frame into 2 side-by-side windows.=

Try this:

Expand emacs to fill the screen.  For me this= is 194x65.
Create a new buffer with just the text I included = in the bug report.
C-x 3
Put something else in the left window and go the r= ight window.
Page down several times.

The last page down I find takes 5-8 seconds repeat= edly.

I don't see as bad behavior when the text is in th= e left buffer or if I have only
1 window.

And disabling bidi reordering completely eliminate= s the bad behavior.


Thanks
Jerry
= --0__=0ABBF16DDFC0A51D8f9e8a93df938690918c0ABBF16DDFC0A51D-- From debbugs-submit-bounces@debbugs.gnu.org Tue Oct 08 14:07:47 2013 Received: (at 15555) by debbugs.gnu.org; 8 Oct 2013 18:07:47 +0000 Received: from localhost ([127.0.0.1]:35489 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VTbhC-0004il-NT for submit@debbugs.gnu.org; Tue, 08 Oct 2013 14:07:46 -0400 Received: from mtaout23.012.net.il ([80.179.55.175]:58431) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VTbh9-0004ia-N1 for 15555@debbugs.gnu.org; Tue, 08 Oct 2013 14:07:45 -0400 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0MUD003003N9XD00@a-mtaout23.012.net.il> for 15555@debbugs.gnu.org; Tue, 08 Oct 2013 21:07:42 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MUD0031K3OSVB40@a-mtaout23.012.net.il>; Tue, 08 Oct 2013 21:07:42 +0300 (IDT) Date: Tue, 08 Oct 2013 21:07:39 +0300 From: Eli Zaretskii Subject: Re: bug#15555: 24.3; Bidirectional display very slow with long lines In-reply-to: X-012-Sender: halo1@inter.net.il To: Jerome L Quinn Message-id: <8338obskk4.fsf@gnu.org> References: <83wqlo461e.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 15555 Cc: 15555@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Cc: 15555@debbugs.gnu.org > From: Jerome L Quinn > Date: Tue, 8 Oct 2013 11:39:58 -0400 > > I'm not sure it is the same bug. When I disable the bidi reordering > variable, > navigation speed becomes reasonable, even with the very long line length. > I'm on a very fast machine, so #13675 may not be impacting me that badly. > > When bidi reordering is enabled, it is multiple seconds to move the > cursor up and down, which is unusable. You are on a very fast machine, so you don't see the slow redisplay with such lines. But the basic problem remains: Emacs does not cope well with long lines. It's just that in your case the border of "unbearable" is farther. > Setting bidi-paragraph-direction to right-to-left improves the > situation some but I'd still call it unusable in this situation. > Disabling reordering makes emacs as responsive as I'd expect, > comparable to emacs23. Emacs 24 cannot possibly work as fast as Emacs 23, since reordering of bidirectional text does need a lot of additional processing. There's nothing that can be done about that, without a complete rewrite of the Emacs display engine (or purchasing a faster machine). > I don't see as bad behavior when the text is in the left buffer or > if I have only 1 window. Then don't do that. Again, these all are signs of slow redisplay with long lines. They just become a bot faster or slower in specific situations and screen arrangements. > And disabling bidi reordering completely eliminates the bad behavior. If you can afford that, go for it. From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 09 08:27:01 2013 Received: (at 15555) by debbugs.gnu.org; 9 Oct 2013 12:27:01 +0000 Received: from localhost ([127.0.0.1]:37104 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VTsqy-0000vd-GP for submit@debbugs.gnu.org; Wed, 09 Oct 2013 08:27:00 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.182]:54219) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VTsqx-0000vW-06 for 15555@debbugs.gnu.org; Wed, 09 Oct 2013 08:26:59 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABK/CFHO+K8t/2dsb2JhbABEvw4Xc4IeAQEEAVYjEAs0EhQYDSSIHgbBLZEKA6R6gV6DEw X-IPAS-Result: Av4EABK/CFHO+K8t/2dsb2JhbABEvw4Xc4IeAQEEAVYjEAs0EhQYDSSIHgbBLZEKA6R6gV6DEw X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="35099381" Received: from 206-248-175-45.dsl.teksavvy.com (HELO pastel.home) ([206.248.175.45]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 09 Oct 2013 08:23:14 -0400 Received: by pastel.home (Postfix, from userid 20848) id 4245161337; Wed, 9 Oct 2013 08:26:58 -0400 (EDT) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#15555: 24.3; Bidirectional display very slow with long lines Message-ID: References: <83wqlo461e.fsf@gnu.org> <8338obskk4.fsf@gnu.org> Date: Wed, 09 Oct 2013 08:26:58 -0400 In-Reply-To: <8338obskk4.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 08 Oct 2013 21:07:39 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 15555 Cc: Jerome L Quinn , 15555@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) >> And disabling bidi reordering completely eliminates the bad behavior. > If you can afford that, go for it. IIRC this is the first report where setting bidi-display-reordering to nil is really the best recommendation we can offer (and where it apparently indeed helps significantly). I consider bidi-display-reordering as a debugging tool rather than a user config, so I'm not very happy about this situation. Stefan From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 09 12:59:32 2013 Received: (at 15555) by debbugs.gnu.org; 9 Oct 2013 16:59:32 +0000 Received: from localhost ([127.0.0.1]:38115 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VTx6h-0000cT-FG for submit@debbugs.gnu.org; Wed, 09 Oct 2013 12:59:31 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]:43170) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VTx6e-0000cJ-Vb for 15555@debbugs.gnu.org; Wed, 09 Oct 2013 12:59:30 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MUE00100V129T00@a-mtaout20.012.net.il> for 15555@debbugs.gnu.org; Wed, 09 Oct 2013 19:59:27 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MUE0001VV72RJD0@a-mtaout20.012.net.il>; Wed, 09 Oct 2013 19:59:26 +0300 (IDT) Date: Wed, 09 Oct 2013 19:59:26 +0300 From: Eli Zaretskii Subject: Re: bug#15555: 24.3; Bidirectional display very slow with long lines In-reply-to: X-012-Sender: halo1@inter.net.il To: Stefan Monnier Message-id: <83iox6qt1t.fsf@gnu.org> References: <83wqlo461e.fsf@gnu.org> <8338obskk4.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 15555 Cc: jlquinn@us.ibm.com, 15555@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Stefan Monnier > Cc: Jerome L Quinn , 15555@debbugs.gnu.org > Date: Wed, 09 Oct 2013 08:26:58 -0400 > > >> And disabling bidi reordering completely eliminates the bad behavior. > > If you can afford that, go for it. > > IIRC this is the first report where setting bidi-display-reordering to > nil is really the best recommendation we can offer (and where it > apparently indeed helps significantly). Actually, it's not my recommendation. But the OP keeps claiming that nothing else works for him. My recommendation would be rather to make lines shorter. > I consider bidi-display-reordering as a debugging tool rather than > a user config, so I'm not very happy about this situation. I'm not happy either (probably even less than you), but I'm not going to agree that slow redisplay of 14K-character lines has anything to do with bidirectional editing support. _Anything_ that slows down redisplay even a bit will have the same effect with such long lines, e.g., JIT font lock, Flyspell, invisible text, you name it. In fact, even on a reasonably fast machine (mine is a core i7 screamer) Emacs is unbearably slow with such long lines without reordering as well. Maybe the OP has an unreasonably fast machine, but that just makes his use case even more rare. IOW, this is bug #13675, which has nothing to do with bidi. As long as the basic display algorithms are not changed to fix that bug, I'm going to claim that bidi is not the issue here. From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 09 14:04:21 2013 Received: (at 15555) by debbugs.gnu.org; 9 Oct 2013 18:04:21 +0000 Received: from localhost ([127.0.0.1]:38277 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VTy7Q-0003Nd-RK for submit@debbugs.gnu.org; Wed, 09 Oct 2013 14:04:21 -0400 Received: from e9.ny.us.ibm.com ([32.97.182.139]:41830) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VTy7N-0003NU-Ux for 15555@debbugs.gnu.org; Wed, 09 Oct 2013 14:04:18 -0400 Received: from /spool/local by e9.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for <15555@debbugs.gnu.org> from ; Wed, 9 Oct 2013 14:04:16 -0400 Received: from d01dlp03.pok.ibm.com (9.56.250.168) by e9.ny.us.ibm.com (192.168.1.109) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 9 Oct 2013 14:04:14 -0400 Received: from b01cxnp22033.gho.pok.ibm.com (b01cxnp22033.gho.pok.ibm.com [9.57.198.23]) by d01dlp03.pok.ibm.com (Postfix) with ESMTP id 32DAFC90043 for <15555@debbugs.gnu.org>; Wed, 9 Oct 2013 14:04:13 -0400 (EDT) Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by b01cxnp22033.gho.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r99I4Dao52625652 for <15555@debbugs.gnu.org>; Wed, 9 Oct 2013 18:04:13 GMT Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r99I4Dcr018323 for <15555@debbugs.gnu.org>; Wed, 9 Oct 2013 15:04:13 -0300 Received: from d01ml605.pok.ibm.com (d01ml605.pok.ibm.com [9.63.8.148]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id r99I4Dps018315; Wed, 9 Oct 2013 15:04:13 -0300 In-Reply-To: <83iox6qt1t.fsf@gnu.org> References: <83wqlo461e.fsf@gnu.org> <8338obskk4.fsf@gnu.org> <83iox6qt1t.fsf@gnu.org> Subject: Re: bug#15555: 24.3; Bidirectional display very slow with long lines X-KeepSent: BDC2F7EF:E6CC108C-85257BFF:00624440; type=4; name=$KeepSent To: Eli Zaretskii X-Mailer: IBM Notes Release 9.0 March 08, 2013 Message-ID: From: Jerome L Quinn Date: Wed, 9 Oct 2013 14:04:12 -0400 X-MIMETrack: Serialize by Router on D01ML605/01/M/IBM(Release 9.0IF2 |July 03, 2013) at 10/09/2013 02:04:13 PM MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBF16CDFF1C2D08f9e8a93df938690918c0ABBF16CDFF1C2D0" Content-Disposition: inline X-TM-AS-MML: No X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13100918-7182-0000-0000-000008AE8333 X-Spam-Score: -5.2 (-----) X-Debbugs-Envelope-To: 15555 Cc: 15555@debbugs.gnu.org, Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.2 (-----) --0__=0ABBF16CDFF1C2D08f9e8a93df938690918c0ABBF16CDFF1C2D0 Content-type: text/plain; charset=US-ASCII Eli Zaretskii wrote on 10/09/2013 12:59:26 PM: > From: Eli Zaretskii > To: Stefan Monnier > Cc: Jerome L Quinn/Watson/IBM@IBMUS, 15555@debbugs.gnu.org > Date: 10/09/2013 12:59 PM > Subject: Re: bug#15555: 24.3; Bidirectional display very slow with long lines > > > From: Stefan Monnier > > Cc: Jerome L Quinn , 15555@debbugs.gnu.org > > Date: Wed, 09 Oct 2013 08:26:58 -0400 > > > > >> And disabling bidi reordering completely eliminates the bad behavior. > > > If you can afford that, go for it. > > > > IIRC this is the first report where setting bidi-display-reordering to > > nil is really the best recommendation we can offer (and where it > > apparently indeed helps significantly). > > Actually, it's not my recommendation. But the OP keeps claiming that > nothing else works for him. > > My recommendation would be rather to make lines shorter. I can't make the lines shorter. The file I'm looking at is computer-generated. I can disable reordering, which does solve the speed problem for me. I'd just like to help identify the source of the issue so that it can be resolved at some point. > > I consider bidi-display-reordering as a debugging tool rather than > > a user config, so I'm not very happy about this situation. > > I'm not happy either (probably even less than you), but I'm not going > to agree that slow redisplay of 14K-character lines has anything to do > with bidirectional editing support. _Anything_ that slows down > redisplay even a bit will have the same effect with such long lines, > e.g., JIT font lock, Flyspell, invisible text, you name it. In fact, > even on a reasonably fast machine (mine is a core i7 screamer) Emacs > is unbearably slow with such long lines without reordering as well. > Maybe the OP has an unreasonably fast machine, but that just makes his > use case even more rare. I'm not sure what else I can do. I timed how long it takes to page down and move the cursor and it's much slower with reordering enabled on my test case. No, moving around with 14K lines and reordering off is not lightning fast. It is however subsecond response on my machine. Reordering brings subsecond response up to multiple seconds as you are further along the line. I am on a high-end 12 core xeon machine, so yes, the hardware is fast. --0__=0ABBF16CDFF1C2D08f9e8a93df938690918c0ABBF16CDFF1C2D0 Content-type: text/html; charset=US-ASCII Content-Disposition: inline

Eli Zaretskii <eliz@gnu.org> wrote on 10/09/2013 12:59:26 PM:

> From: Eli Zaretskii <eliz@gnu.org>
> To: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Jerome L Quinn/Watson/IBM@IBMUS, 15555@debbugs.gnu.org
> Date: 10/09/2013 12:59 PM
> Subject: Re: bug#15555: 24.3; Bidirectional display very slow with long lines
>
> > From: Stefan Monnier <monnier@iro.umontreal.ca>
> > Cc: Jerome L Quinn <jlquinn@us.ibm.com>,  15555@debbugs.gnu.org
> > Date: Wed, 09 Oct 2013 08:26:58 -0400
> >
> > >> And disabling bidi reordering completely eliminates the bad behavior.
> > > If you can afford that, go for it.
> >
> > IIRC this is the first report where setting bidi-display-reordering to
> > nil is really the best recommendation we can offer (and where it
> > apparently indeed helps significantly).
>
> Actually, it's not my recommendation.  But the OP keeps claiming that
> nothing else works for him.
>
> My recommendation would be rather to make lines shorter.

I can't make the lines shorter.  The file I'm looking at is computer-generated.

I can disable reordering, which does solve the speed problem for me.  I'd just like
to help identify the source of the issue so that it can be resolved at some point.

> > I consider bidi-display-reordering as a debugging tool rather than
> > a user config, so I'm not very happy about this situation.
>
> I'm not happy either (probably even less than you), but I'm not going
> to agree that slow redisplay of 14K-character lines has anything to do
> with bidirectional editing support.  _Anything_ that slows down
> redisplay even a bit will have the same effect with such long lines,
> e.g., JIT font lock, Flyspell, invisible text, you name it.  In fact,
> even on a reasonably fast machine (mine is a core i7 screamer) Emacs
> is unbearably slow with such long lines without reordering as well.
> Maybe the OP has an unreasonably fast machine, but that just makes his
> use case even more rare.

I'm not sure what else I can do.  I timed how long it takes to page down and
move the cursor and it's much slower with reordering enabled on my test
case.

No, moving around with 14K lines and reordering off is not lightning fast.  It
is however subsecond response on my machine.  Reordering brings subsecond
response up to multiple seconds as you are further along the line.

I am on a high-end 12 core xeon machine, so yes, the hardware is fast.


--0__=0ABBF16CDFF1C2D08f9e8a93df938690918c0ABBF16CDFF1C2D0-- From debbugs-submit-bounces@debbugs.gnu.org Mon Feb 10 16:28:32 2014 Received: (at control) by debbugs.gnu.org; 10 Feb 2014 21:28:32 +0000 Received: from localhost ([127.0.0.1]:41898 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WCyP2-0006li-Aa for submit@debbugs.gnu.org; Mon, 10 Feb 2014 16:28:32 -0500 Received: from fencepost.gnu.org ([208.118.235.10]:54336 ident=Debian-exim) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WCyP0-0006la-Qa for control@debbugs.gnu.org; Mon, 10 Feb 2014 16:28:31 -0500 Received: from rgm by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1WCyP0-00055p-JH for control@debbugs.gnu.org; Mon, 10 Feb 2014 16:28:30 -0500 Date: Mon, 10 Feb 2014 16:28:30 -0500 Message-Id: Subject: control message for bug 15555 To: X-Mailer: mail (GNU Mailutils 2.1) From: Glenn Morris X-Spam-Score: -5.6 (-----) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.6 (-----) merge 13675 15555 From debbugs-submit-bounces@debbugs.gnu.org Mon Feb 17 19:55:58 2014 Received: (at control) by debbugs.gnu.org; 18 Feb 2014 00:55:58 +0000 Received: from localhost ([127.0.0.1]:57281 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WFYyb-0007Tu-V8 for submit@debbugs.gnu.org; Mon, 17 Feb 2014 19:55:58 -0500 Received: from fencepost.gnu.org ([208.118.235.10]:43970 ident=Debian-exim) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WFYya-0007Tn-Gm for control@debbugs.gnu.org; Mon, 17 Feb 2014 19:55:56 -0500 Received: from rgm by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1WFYya-0006lK-9g for control@debbugs.gnu.org; Mon, 17 Feb 2014 19:55:56 -0500 Date: Mon, 17 Feb 2014 19:55:56 -0500 Message-Id: Subject: control message for bug 16786 To: X-Mailer: mail (GNU Mailutils 2.1) From: Glenn Morris X-Spam-Score: -5.6 (-----) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.6 (-----) merge 3219 16786 From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 18 02:32:35 2014 Received: (at control) by debbugs.gnu.org; 18 Feb 2014 07:32:36 +0000 Received: from localhost ([127.0.0.1]:57477 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WFfAR-0003ih-B6 for submit@debbugs.gnu.org; Tue, 18 Feb 2014 02:32:35 -0500 Received: from fencepost.gnu.org ([208.118.235.10]:50395 ident=Debian-exim) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WFfAP-0003iX-4A for control@debbugs.gnu.org; Tue, 18 Feb 2014 02:32:33 -0500 Received: from rgm by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1WFfAO-00021i-HV for control@debbugs.gnu.org; Tue, 18 Feb 2014 02:32:32 -0500 Date: Tue, 18 Feb 2014 02:32:32 -0500 Message-Id: Subject: control message for bug 16786 To: X-Mailer: mail (GNU Mailutils 2.1) From: Glenn Morris X-Spam-Score: -5.6 (-----) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.6 (-----) unmerge 16786 From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 18 07:44:04 2014 Received: (at 15555) by debbugs.gnu.org; 18 Feb 2014 12:44:04 +0000 Received: from localhost ([127.0.0.1]:57791 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WFk1r-0006Z6-1i for submit@debbugs.gnu.org; Tue, 18 Feb 2014 07:44:03 -0500 Received: from mail.dev.rtsoft.ru ([213.79.90.226]:39924 helo=dev.rtsoft.ru) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WFk1n-0006YP-VK for 15555@debbugs.gnu.org; Tue, 18 Feb 2014 07:44:01 -0500 Received: from localhost.localdomain (fw-int.dev.rtsoft.ru [192.168.1.70]) by dev.rtsoft.ru (Postfix) with ESMTP id 05DE34132E; Tue, 18 Feb 2014 16:43:52 +0400 (MSK) Message-ID: <53035588.3080705@dev.rtsoft.ru> Date: Tue, 18 Feb 2014 16:43:52 +0400 From: Dmitry Antipov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: Re: bug#15555: 24.3; Bidirectional display very slow with long lines References: <83wqlo461e.fsf@gnu.org> <8338obskk4.fsf@gnu.org> <83iox6qt1t.fsf@gnu.org> In-Reply-To: <83iox6qt1t.fsf@gnu.org> Content-Type: multipart/mixed; boundary="------------020204060209040002070109" X-Spam-Score: -0.6 (/) X-Debbugs-Envelope-To: 15555 Cc: 15555@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.6 (/) This is a multi-part message in MIME format. --------------020204060209040002070109 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 10/09/2013 08:59 PM, Eli Zaretskii wrote: > IOW, this is bug #13675, which has nothing to do with bidi. As long > as the basic display algorithms are not changed to fix that bug, I'm > going to claim that bidi is not the issue here. Hm... I have two files, with 2000 and 4000 first chars extracted from the beginning of the monster string from http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15555#5. The following function: (defun bug15555 () (interactive) (while (not (eobp)) (right-char 1) (redisplay) (sleep-for 0.01))) runs smoothly over 2000.txt, but painfully slow over 4000.txt. The latter case also shows the very pathological profile with ~25% CPU spent in memcpy. Are you sure that bidi_copy_it doesn't add one more bottleneck to the whole stuff? Dmitry --------------020204060209040002070109 Content-Type: text/plain; charset=UTF-8; name="2000.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="2000.txt" W1tudWxsLFsicmF3Il0sW1si2YPZhCDZh9iw2Kcg2KfZhNmD2LHZh9iMINmB2KfYpti2INin 2YTZg9ix2KfZh9mK2Kkg2K3Yp9mE2Kkg2LrYqNmK2Kkg2KrZhNmB2YbYpyDZhdmGINmD2YQg 2KzYp9mG2KjYjCDYudmG2K/ZhdinINmK2KrZhdmG2LfZgiDYp9mE2KjYudi2INio2KfZhNmD 2LHYp9mH2YrYqdiMINi52YbYr9mF2Kcg2YrYudiq2YXZhCDYp9mE2KvYo9ixINmB2Ykg2KfZ hNmG2YHZiNiz2Iwg2KrYtdmK2LEg2YLZhtin2KjZhCDYqNi02LHZitipINiq2YXYtNmJINi5 2YTZiSDZgtiv2YXZitmG2Iwg2KXZhiDYsdij2Kog2YbYp9ix2Kcg2KrYtdioINmF2YYg2YbZ gdmI2LPZh9inINio2YbYstmK2YbYp9iMINin2YTZg9ix2KfZh9mK2Kkg2K3Yp9mE2Kkg2YXY sdi22YrYqSDYqtiz2KrYqNivINio2KfZhNmI2LfZhtiMINiq2LnYqNmK2LEg2YPYp9ix2Ycg 2LnZhiDYuti22Kgg2YXYs9iq2LfZitixLi4g2YTYpyDZitmB2LHZgiDZg9ir2YrYsdinINi5 2YYg2KfZhNi02LHYsSDYp9mE2YXYs9iq2LfZitix2Iwg2YbZitix2KfZhiDYp9mE2YPYsdin 2YfZitipINiq2LnYqtmF2YQg2YHZiSDYp9mE2LXYr9mI2LHYjCDYrdmF2YUg2YTZiCDYqti5 2YTZhdmI2YYuIixbLTEsMCwzMjJdXV1dLFsicmF3IixbInJhd3RleHQiXSxbWyLZg9mEINmH 2LDYpyDYp9mE2YPYsdmH2Iwg2YHYp9im2LYg2KfZhNmD2LHYp9mH2YrYqSDYrdin2YTYqSDY utio2YrYqSDYqtmE2YHZhtinINmF2YYg2YPZhCDYrNin2YbYqNiMINi52YbYr9mF2Kcg2YrY qtmF2YbYt9mCINin2YTYqNi52LYg2KjYp9mE2YPYsdin2YfZitip2Iwg2LnZhtiv2YXYpyDZ iti52KrZhdmEINin2YTYq9ij2LEg2YHZiSDYp9mE2YbZgdmI2LPYjCDYqti12YrYsSDZgtmG 2KfYqNmEINio2LTYsdmK2Kkg2KrZhdi02Ykg2LnZhNmJINmC2K/ZhdmK2YbYjCDYpdmGINix 2KPYqiDZhtin2LHYpyDYqti12Kgg2YXZhiDZhtmB2YjYs9mH2Kcg2KjZhtiy2YrZhtin2Iwg 2KfZhNmD2LHYp9mH2YrYqSDYrdin2YTYqSDZhdix2LbZitipINiq2LPYqtio2K8g2KjYp9mE 2YjYt9mG2Iwg2KrYudio2YrYsSDZg9in2LHZhyDYudmGINi62LbYqCDZhdiz2KrYt9mK2LEu LiDZhNinINmK2YHYsdmCINmD2KvZitix2Kcg2LnZhiDYp9mE2LTYsdixINin2YTZhdiz2KrY t9mK2LHYjCDZhtmK2LHYp9mGINin2YTZg9ix2KfZh9mK2Kkg2KrYudiq2YXZhCDZgdmJINin 2YTYtdiv2YjYsdiMINit2YXZhSDZhNmIINiq2LnZhNmF2YjZhi4iLFswLDAsMzIyXV1dXSxb InJhd3RleHQiLFsidGV4dCJdLFtbItmD2YQg2YfYsNinINin2YTZg9ix2YfYjCDZgdin2KbY tiDYp9mE2YPYsdin2YfZitipINit2KfZhNipINi62KjZitipINiq2YTZgdmG2Kcg2YXZhiDZ g9mEINis2KfZhtio2Iwg2LnZhtiv2YXYpyDZitiq2YXZhti32YIg2KfZhNio2LnYtiDYqNin 2YTZg9ix2KfZh9mK2KnYjCDYudmG2K/ZhdinINmK2LnYqtmF2YQg2KfZhNir2KPYsSDZgdmJ INin2YTZhtmB2YjYs9iMINiq2LXZitixINmC2YbYp9io2YQg2KjYtNix2YrYqSDYqtmF2LTZ iSDYudmE2Ykg2YLYr9mF2YrZhtiMINil2YYg2LHYo9iqINmG2KfYsdinINiq2LXYqCDZhdmG INmG2YHZiNiz2YfYpyDYqNmG2LLZitmG2KfYjCDYp9mE2YPYsdin2YfZitipINit2KfZhNip INmF2LHYttmK2Kkg2KrYs9iq2KjYryDYqNin2YTZiNi32YbYjCDYqti52KjZitixINmD2KfY sdmHINi52YYg2LrYttioINmF2LPYqti32YrYsS4uINmE2Kcg2YrZgdix2YIg2YPYq9mK2LHY pyDYudmGINin2YTYtNix2LEg2KfZhNmF2LPYqti32YrYsdiMINmG2YrYsdin2YYg2KfZhNmD 2LHYp9mH2YrYqSDYqti52KrZhdmEINmB2Ykg2KfZhNi12K/ZiNix2Iwg2K3ZhdmFINmE2Ygg 2KrYudmE2YXZiNmGLiIsWzAsMCwzMjJdXV1dLFsidGV4dCIsWyJyYXd0b2siLCJ0b2t0eXBl Il0sW1si2YPZhCIsIjAiLFswLDAsMl1dLFsi2YfYsNinIiwiMCIsWzAsMyw2XV0sWyLYp9mE 2YPYsdmHIiwiMCIsWzAsNywxMl1dLFsi2IwiLCIyMDQ4IixbMCwxMiwxM11dLFsi2YHYp9im 2LYiLCIwIixbMCwxNCwxOF1dLFsi2KfZhNmD2LHYp9mH2YrYqSIsIjAiLFswLDE5LDI3XV0s WyLYrdin2YTYqSIsIjAiLFswLDI4LDMyXV0sWyLYutio2YrYqSIsIjAiLFswLDMzLDM3XV0s WyLYqtmE2YHZhtinIiwiMCIsWzAsMzgsNDNdXSxbItmF2YYiLCIwIixbMCw0NCw0Nl1dLFsi 2YPZhCIsIjAiLFswLDQ3LDQ5XV0sWyLYrNin2YbYqCIsIjAiLFswLDUwLDU0XV0sWyLYjCIs IjIwNDgiLFswLDU0LDU1XV0sWyLYudmG2K/ZhdinIiwiMCIsWzAsNTYsNjFdXSxbItmK2KrZ hdmG2LfZgiIsIjAiLFswLDYyLDY4XV0sWyLYp9mE2KjYudi2IiwiMCIsWzAsNjksNzRdXSxb Itio2KfZhNmD2LHYp9mH2YrYqSIsIjAiLFswLDc1LDg0XV0sWyLYjCIsIjIwNDgiLFswLDg0 LDg1XV0sWyLYudmG2K/ZhdinIiwiMCIsWzAsODYsOTFdXSxbItmK2LnYqtmF2YQiLCIwIixb MCw5Miw5N11dLFsi2KfZhNir2KPYsSIsIjAiLFswLDk4LDEwM11dLFsi2YHZiSIsIjAiLFsw LDEwNCwxMDZdXSxbItin2YTZhtmB2YjYsyIsIjAiLFswLDEwNywxMTNdXSxbItiMIiwiMjA0 OCIsWzAsMTEzLDExNF1dLFsi2KrYtdmK2LEiLCIwIixbMCwxMTUsMTE5XV0sWyLZgtmG2KfY qNmEIiwiMCIsWzAsMTIwLDEyNV1dLFsi2KjYtNix2YrYqSIsIjAiLFswLDEyNiwxMzFdXSxb Itiq2YXYtNmJIiwiMCIsWzAsMTMyLDEzNl1dLFsi2LnZhNmJIiwiMCIsWzAsMTM3LDE0MF1d LFsi2YLYr9mF2YrZhiIsIjAiLFswLDE0MSwxNDZdXSxbItiMIiwiMjA0OCIsWzAsMTQ2LDE0 N11dLFsi2KXZhiIsIjAiLFswLDE0OCwxNTBdXSxbItix2KPYqiIsIjAiLFswLDE1MSwxNTRd XSxbItmG2KfYsdinIiwiMCIsWzAsMTU1LDE1OV1dLFsi2KrYtdioIiwiMCIsWzAsMTYwLDE2 M11dLFsi2YXZhiIsIjAiLFswLDE2NCwxNjZdXSxbItmG2YHZiNiz2YfYpyIsIjAiLFswLDE2 NywxNzNdXSxbItio2YbYstmKCg== --------------020204060209040002070109 Content-Type: text/plain; charset=UTF-8; name="4000.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="4000.txt" W1tudWxsLFsicmF3Il0sW1si2YPZhCDZh9iw2Kcg2KfZhNmD2LHZh9iMINmB2KfYpti2INin 2YTZg9ix2KfZh9mK2Kkg2K3Yp9mE2Kkg2LrYqNmK2Kkg2KrZhNmB2YbYpyDZhdmGINmD2YQg 2KzYp9mG2KjYjCDYudmG2K/ZhdinINmK2KrZhdmG2LfZgiDYp9mE2KjYudi2INio2KfZhNmD 2LHYp9mH2YrYqdiMINi52YbYr9mF2Kcg2YrYudiq2YXZhCDYp9mE2KvYo9ixINmB2Ykg2KfZ hNmG2YHZiNiz2Iwg2KrYtdmK2LEg2YLZhtin2KjZhCDYqNi02LHZitipINiq2YXYtNmJINi5 2YTZiSDZgtiv2YXZitmG2Iwg2KXZhiDYsdij2Kog2YbYp9ix2Kcg2KrYtdioINmF2YYg2YbZ gdmI2LPZh9inINio2YbYstmK2YbYp9iMINin2YTZg9ix2KfZh9mK2Kkg2K3Yp9mE2Kkg2YXY sdi22YrYqSDYqtiz2KrYqNivINio2KfZhNmI2LfZhtiMINiq2LnYqNmK2LEg2YPYp9ix2Ycg 2LnZhiDYuti22Kgg2YXYs9iq2LfZitixLi4g2YTYpyDZitmB2LHZgiDZg9ir2YrYsdinINi5 2YYg2KfZhNi02LHYsSDYp9mE2YXYs9iq2LfZitix2Iwg2YbZitix2KfZhiDYp9mE2YPYsdin 2YfZitipINiq2LnYqtmF2YQg2YHZiSDYp9mE2LXYr9mI2LHYjCDYrdmF2YUg2YTZiCDYqti5 2YTZhdmI2YYuIixbLTEsMCwzMjJdXV1dLFsicmF3IixbInJhd3RleHQiXSxbWyLZg9mEINmH 2LDYpyDYp9mE2YPYsdmH2Iwg2YHYp9im2LYg2KfZhNmD2LHYp9mH2YrYqSDYrdin2YTYqSDY utio2YrYqSDYqtmE2YHZhtinINmF2YYg2YPZhCDYrNin2YbYqNiMINi52YbYr9mF2Kcg2YrY qtmF2YbYt9mCINin2YTYqNi52LYg2KjYp9mE2YPYsdin2YfZitip2Iwg2LnZhtiv2YXYpyDZ iti52KrZhdmEINin2YTYq9ij2LEg2YHZiSDYp9mE2YbZgdmI2LPYjCDYqti12YrYsSDZgtmG 2KfYqNmEINio2LTYsdmK2Kkg2KrZhdi02Ykg2LnZhNmJINmC2K/ZhdmK2YbYjCDYpdmGINix 2KPYqiDZhtin2LHYpyDYqti12Kgg2YXZhiDZhtmB2YjYs9mH2Kcg2KjZhtiy2YrZhtin2Iwg 2KfZhNmD2LHYp9mH2YrYqSDYrdin2YTYqSDZhdix2LbZitipINiq2LPYqtio2K8g2KjYp9mE 2YjYt9mG2Iwg2KrYudio2YrYsSDZg9in2LHZhyDYudmGINi62LbYqCDZhdiz2KrYt9mK2LEu LiDZhNinINmK2YHYsdmCINmD2KvZitix2Kcg2LnZhiDYp9mE2LTYsdixINin2YTZhdiz2KrY t9mK2LHYjCDZhtmK2LHYp9mGINin2YTZg9ix2KfZh9mK2Kkg2KrYudiq2YXZhCDZgdmJINin 2YTYtdiv2YjYsdiMINit2YXZhSDZhNmIINiq2LnZhNmF2YjZhi4iLFswLDAsMzIyXV1dXSxb InJhd3RleHQiLFsidGV4dCJdLFtbItmD2YQg2YfYsNinINin2YTZg9ix2YfYjCDZgdin2KbY tiDYp9mE2YPYsdin2YfZitipINit2KfZhNipINi62KjZitipINiq2YTZgdmG2Kcg2YXZhiDZ g9mEINis2KfZhtio2Iwg2LnZhtiv2YXYpyDZitiq2YXZhti32YIg2KfZhNio2LnYtiDYqNin 2YTZg9ix2KfZh9mK2KnYjCDYudmG2K/ZhdinINmK2LnYqtmF2YQg2KfZhNir2KPYsSDZgdmJ INin2YTZhtmB2YjYs9iMINiq2LXZitixINmC2YbYp9io2YQg2KjYtNix2YrYqSDYqtmF2LTZ iSDYudmE2Ykg2YLYr9mF2YrZhtiMINil2YYg2LHYo9iqINmG2KfYsdinINiq2LXYqCDZhdmG INmG2YHZiNiz2YfYpyDYqNmG2LLZitmG2KfYjCDYp9mE2YPYsdin2YfZitipINit2KfZhNip INmF2LHYttmK2Kkg2KrYs9iq2KjYryDYqNin2YTZiNi32YbYjCDYqti52KjZitixINmD2KfY sdmHINi52YYg2LrYttioINmF2LPYqti32YrYsS4uINmE2Kcg2YrZgdix2YIg2YPYq9mK2LHY pyDYudmGINin2YTYtNix2LEg2KfZhNmF2LPYqti32YrYsdiMINmG2YrYsdin2YYg2KfZhNmD 2LHYp9mH2YrYqSDYqti52KrZhdmEINmB2Ykg2KfZhNi12K/ZiNix2Iwg2K3ZhdmFINmE2Ygg 2KrYudmE2YXZiNmGLiIsWzAsMCwzMjJdXV1dLFsidGV4dCIsWyJyYXd0b2siLCJ0b2t0eXBl Il0sW1si2YPZhCIsIjAiLFswLDAsMl1dLFsi2YfYsNinIiwiMCIsWzAsMyw2XV0sWyLYp9mE 2YPYsdmHIiwiMCIsWzAsNywxMl1dLFsi2IwiLCIyMDQ4IixbMCwxMiwxM11dLFsi2YHYp9im 2LYiLCIwIixbMCwxNCwxOF1dLFsi2KfZhNmD2LHYp9mH2YrYqSIsIjAiLFswLDE5LDI3XV0s WyLYrdin2YTYqSIsIjAiLFswLDI4LDMyXV0sWyLYutio2YrYqSIsIjAiLFswLDMzLDM3XV0s WyLYqtmE2YHZhtinIiwiMCIsWzAsMzgsNDNdXSxbItmF2YYiLCIwIixbMCw0NCw0Nl1dLFsi 2YPZhCIsIjAiLFswLDQ3LDQ5XV0sWyLYrNin2YbYqCIsIjAiLFswLDUwLDU0XV0sWyLYjCIs IjIwNDgiLFswLDU0LDU1XV0sWyLYudmG2K/ZhdinIiwiMCIsWzAsNTYsNjFdXSxbItmK2KrZ hdmG2LfZgiIsIjAiLFswLDYyLDY4XV0sWyLYp9mE2KjYudi2IiwiMCIsWzAsNjksNzRdXSxb Itio2KfZhNmD2LHYp9mH2YrYqSIsIjAiLFswLDc1LDg0XV0sWyLYjCIsIjIwNDgiLFswLDg0 LDg1XV0sWyLYudmG2K/ZhdinIiwiMCIsWzAsODYsOTFdXSxbItmK2LnYqtmF2YQiLCIwIixb MCw5Miw5N11dLFsi2KfZhNir2KPYsSIsIjAiLFswLDk4LDEwM11dLFsi2YHZiSIsIjAiLFsw LDEwNCwxMDZdXSxbItin2YTZhtmB2YjYsyIsIjAiLFswLDEwNywxMTNdXSxbItiMIiwiMjA0 OCIsWzAsMTEzLDExNF1dLFsi2KrYtdmK2LEiLCIwIixbMCwxMTUsMTE5XV0sWyLZgtmG2KfY qNmEIiwiMCIsWzAsMTIwLDEyNV1dLFsi2KjYtNix2YrYqSIsIjAiLFswLDEyNiwxMzFdXSxb Itiq2YXYtNmJIiwiMCIsWzAsMTMyLDEzNl1dLFsi2LnZhNmJIiwiMCIsWzAsMTM3LDE0MF1d LFsi2YLYr9mF2YrZhiIsIjAiLFswLDE0MSwxNDZdXSxbItiMIiwiMjA0OCIsWzAsMTQ2LDE0 N11dLFsi2KXZhiIsIjAiLFswLDE0OCwxNTBdXSxbItix2KPYqiIsIjAiLFswLDE1MSwxNTRd XSxbItmG2KfYsdinIiwiMCIsWzAsMTU1LDE1OV1dLFsi2KrYtdioIiwiMCIsWzAsMTYwLDE2 M11dLFsi2YXZhiIsIjAiLFswLDE2NCwxNjZdXSxbItmG2YHZiNiz2YfYpyIsIjAiLFswLDE2 NywxNzNdXSxbItio2YbYstmK2YbYpyIsIjAiLFswLDE3NCwxODBdXSxbItiMIiwiMjA0OCIs WzAsMTgwLDE4MV1dLFsi2KfZhNmD2LHYp9mH2YrYqSIsIjAiLFswLDE4MiwxOTBdXSxbItit 2KfZhNipIiwiMCIsWzAsMTkxLDE5NV1dLFsi2YXYsdi22YrYqSIsIjAiLFswLDE5NiwyMDFd XSxbItiq2LPYqtio2K8iLCIwIixbMCwyMDIsMjA3XV0sWyLYqNin2YTZiNi32YYiLCIwIixb MCwyMDgsMjE0XV0sWyLYjCIsIjIwNDgiLFswLDIxNCwyMTVdXSxbItiq2LnYqNmK2LEiLCIw IixbMCwyMTYsMjIxXV0sWyLZg9in2LHZhyIsIjAiLFswLDIyMiwyMjZdXSxbIti52YYiLCIw IixbMCwyMjcsMjI5XV0sWyLYuti22KgiLCIwIixbMCwyMzAsMjMzXV0sWyLZhdiz2KrYt9mK 2LEiLCIwIixbMCwyMzQsMjQwXV0sWyIuLiIsIjAiLFswLDI0MCwyNDJdXSxbItmE2KciLCIw IixbMCwyNDMsMjQ1XV0sWyLZitmB2LHZgiIsIjAiLFswLDI0NiwyNTBdXSxbItmD2KvZitix 2KciLCIwIixbMCwyNTEsMjU2XV0sWyLYudmGIiwiMCIsWzAsMjU3LDI1OV1dLFsi2KfZhNi0 2LHYsSIsIjAiLFswLDI2MCwyNjVdXSxbItin2YTZhdiz2KrYt9mK2LEiLCIwIixbMCwyNjYs Mjc0XV0sWyLYjCIsIjIwNDgiLFswLDI3NCwyNzVdXSxbItmG2YrYsdin2YYiLCIwIixbMCwy NzYsMjgxXV0sWyLYp9mE2YPYsdin2YfZitipIiwiMCIsWzAsMjgyLDI5MF1dLFsi2KrYudiq 2YXZhCIsIjAiLFswLDI5MSwyOTZdXSxbItmB2YkiLCIwIixbMCwyOTcsMjk5XV0sWyLYp9mE 2LXYr9mI2LEiLCIwIixbMCwzMDAsMzA2XV0sWyLYjCIsIjIwNDgiLFswLDMwNiwzMDddXSxb Itit2YXZhSIsIjAiLFswLDMwOCwzMTFdXSxbItmE2YgiLCIwIixbMCwzMTIsMzE0XV0sWyLY qti52YTZhdmI2YYiLCIwIixbMCwzMTUsMzIxXV0sWyIuIiwiNjE0NCIsWzAsMzIxLDMyMl1d XV0sWyJyYXd0b2siLFsidG9rIl0sW1si2YPZhCIsWzAsMCwyXV0sWyLZh9iw2KciLFsxLDMs Nl1dLFsi2KfZhNmD2LHZhyIsWzIsNywxMl1dLFsiLCIsWzMsMTMsMTRdXSxbItmB2KfYpti2 IixbNCwxNSwxOV1dLFsi2KfZhNmD2LHYp9mH2YrYqSIsWzUsMjAsMjhdXSxbItit2KfZhNip IixbNiwyOSwzM11dLFsi2LrYqNmK2KkiLFs3LDM0LDM4XV0sWyLYqtmE2YHZhtinIixbOCwz OSw0NF1dLFsi2YXZhiIsWzksNDUsNDddXSxbItmD2YQiLFsxMCw0OCw1MF1dLFsi2KzYp9mG 2KgiLFsxMSw1MSw1NV1dLFsiLCIsWzEyLDU2LDU3XV0sWyLYudmG2K/ZhdinIixbMTMsNTgs NjNdXSxbItmK2KrZhdmG2LfZgiIsWzE0LDY0LDcwXV0sWyLYp9mE2KjYudi2IixbMTUsNzEs NzZdXSxbItio2KfZhNmD2LHYp9mH2YrYqSIsWzE2LDc3LDg2XV0sWyIsIixbMTcsODcsODhd XSxbIti52YbYr9mF2KciLFsxOCw4OSw5NF1dLFsi2YrYudiq2YXZhCIsWzE5LDk1LDEwMF1d LFsi2KfZhNir2KPYsSIsWzIwLDEwMSwxMDZdXSxbItmB2YkiLFsyMSwxMDcsMTA5XV0sWyLY p9mE2YbZgdmI2LMiLFsyMiwxMTAsMTE2XV0sWyIsIixbMjMsMTE3LDExOF1dLFsi2KrYtdmK 2LEiLFsyNCwxMTksMTIzXV0sWyLZgtmG2KfYqNmEIixbMjUsMTI0LDEyOV1dLFsi2KjYtNix 2YrYqSIsWzI2LDEzMCwxMzVdXSxbItiq2YXYtNmJIixbMjcsMTM2LDE0MF1dLFsi2LnZhNmJ IixbMjgsMTQxLDE0NF1dLFsi2YLYr9mF2YrZhiIsWzI5LDE0NSwxNTBdXSxbIiwiLFszMCwx NTEsMTUyXV0sWyLYpdmGIixbMzEsMTUzLDE1NV1dLFsi2LHYo9iqIixbMzIsMTU2LDE1OV1d LFsi2YbYp9ix2KciLFszMywxNjAsMTY0XV0sWyLYqti12KgiLFszNCwxNjUsMTY4XV0sWyLZ hdmGIixbMzUsMTY5LDE3MV1dLFsi2YbZgdmI2LPZh9inIixbMzYsMTcyLDE3OF1dLFsi2KjZ htiy2YrZhtinIixbMzcsMTc5LDE4NV1dLFsiLCIsWzM4LDE4NiwxODddXSxbItin2YTZg9ix 2KfZh9mK2KkiLFszOSwxODgsMTk2XV0sWyLYrdin2YTYqSIsWzQwLDE5NywyMDFdXSxbItmF 2LHYttmK2KkiLFs0MSwyMDIsMjA3XV0sWyLYqtiz2KrYqNivIixbNDIsMjA4LDIxM11dLFsi 2KjYp9mE2YjYt9mGIixbNDMsMjE0LDIyMF1dLFsiLCIsWzQ0LDIyMSwyMjJdXSxbItiq2LnY qNmK2LEiLFs0NSwyMjMsMjI4XV0sWyLZg9in2LHZhyIsWzQ2LDIyOSwyMzNdXSxbIti52YYi LFs0NywyMzQsMjM2XV0sWyLYuti22KgiLFs0OCwyMzcsMjQwXV0sWyLZhdiz2KrYt9mK2LEi LFs0OSwyNDEsMjQ3XV0sWyIuLiIsWzUwLDI0OCwyNTBdXSxbItmE2KciLFs1MSwyNTEsMjUz XV0sWyLZitmB2LHZgiIsWzUyLDI1NCwyNThdXSxbItmD2KvZitix2KciLFs1MywyNTksMjY0 XV0sWyLYudmGIixbNTQsMjY1LDI2N11dLFsi2KfZhNi02LHYsSIsWzU1LDI2OCwyNzNdXSxb Itin2YTZhdiz2KrYt9mK2LEiLFs1NiwyNzQsMjgyCg== --------------020204060209040002070109-- From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 18 09:01:19 2014 Received: (at 15555) by debbugs.gnu.org; 18 Feb 2014 14:01:20 +0000 Received: from localhost ([127.0.0.1]:57825 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WFlEd-0000JL-J6 for submit@debbugs.gnu.org; Tue, 18 Feb 2014 09:01:19 -0500 Received: from forward12.mail.yandex.net ([95.108.130.94]:38221) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WFlEZ-0000J4-VM for 15555@debbugs.gnu.org; Tue, 18 Feb 2014 09:01:17 -0500 Received: from smtp12.mail.yandex.net (smtp12.mail.yandex.net [95.108.131.191]) by forward12.mail.yandex.net (Yandex) with ESMTP id 3CE5DC20729; Tue, 18 Feb 2014 18:01:07 +0400 (MSK) Received: from smtp12.mail.yandex.net (localhost [127.0.0.1]) by smtp12.mail.yandex.net (Yandex) with ESMTP id 0036C16A0138; Tue, 18 Feb 2014 18:01:06 +0400 (MSK) Received: from unknown (unknown [37.139.80.10]) by smtp12.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id YJEguSA2gI-16IuE96J; Tue, 18 Feb 2014 18:01:06 +0400 (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: ce0f3bb9-cfff-4edb-b99b-bfee8891a145 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1392732066; bh=FwKwNiurMHEj3zZPhULOuuYwPjzs9cBL/qWWD8A4la4=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=YdILxHTfOYOxRxn/HMzS9q5MSBnKom/iIPrr0vNvbBhPuD0jDvAhWVrF6WJqHTFJu TXzUF1Vy/xBwykoVZl6gDGJtTzDyVBTCgxDjzI3p5gxKbekIcGJO+Pw5yZIDjBBpdT +OgYLYLyU+akcEhXAVhfUmHpJfOWypDxdWSOb3TY= Authentication-Results: smtp12.mail.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <530367A1.3010002@yandex.ru> Date: Tue, 18 Feb 2014 18:01:05 +0400 From: Dmitry Antipov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: bug#15555: 24.3; Bidirectional display very slow with long lines References: <83wqlo461e.fsf@gnu.org> <8338obskk4.fsf@gnu.org> <83iox6qt1t.fsf@gnu.org> <53035588.3080705@dev.rtsoft.ru> In-Reply-To: <53035588.3080705@dev.rtsoft.ru> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 15555 Cc: 15555@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 02/18/2014 04:43 PM, Dmitry Antipov wrote: > Are you sure that bidi_copy_it doesn't add one more bottleneck to the whole > stuff? There is a busy bidi_shelve_cache/bidi_unshelve_cache loop which processes ~1.5M of cache data per each iteration. That's why memcpy takes ~25% in the overall profile... Dmitry From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 18 09:05:05 2014 Received: (at 15555) by debbugs.gnu.org; 18 Feb 2014 14:05:05 +0000 Received: from localhost ([127.0.0.1]:57829 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WFlIH-0000Q8-5m for submit@debbugs.gnu.org; Tue, 18 Feb 2014 09:05:05 -0500 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:37182) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WFlIE-0000PX-6D for 15555@debbugs.gnu.org; Tue, 18 Feb 2014 09:05:02 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABK/CFFLd/lO/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLNBIUGA0kiB4GsR+QDpEKA4hhnBmBXoMV X-IPAS-Result: Av4EABK/CFFLd/lO/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLNBIUGA0kiB4GsR+QDpEKA4hhnBmBXoMV X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="47952692" Received: from 75-119-249-78.dsl.teksavvy.com (HELO pastel.home) ([75.119.249.78]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 18 Feb 2014 09:04:56 -0500 Received: by pastel.home (Postfix, from userid 20848) id 0F0CA6008B; Tue, 18 Feb 2014 09:04:56 -0500 (EST) From: Stefan Monnier To: Dmitry Antipov Subject: Re: bug#15555: Re: bug#15555: 24.3; Bidirectional display very slow with long lines Message-ID: References: <83wqlo461e.fsf@gnu.org> <8338obskk4.fsf@gnu.org> <83iox6qt1t.fsf@gnu.org> <53035588.3080705@dev.rtsoft.ru> Date: Tue, 18 Feb 2014 09:04:56 -0500 In-Reply-To: <53035588.3080705@dev.rtsoft.ru> (Dmitry Antipov's message of "Tue, 18 Feb 2014 16:43:52 +0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 15555 Cc: Eli Zaretskii , 15555@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) > Are you sure that bidi_copy_it doesn't add one more bottleneck to the whole > stuff? Eli's argument is not that bidi adds its own bottlenecks, but that there are sufficiently other bottlenecks that there's not much point trying to address bidi's bottlenecks until we start tackling the other ones. Stefan From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 18 09:31:36 2014 Received: (at 15555) by debbugs.gnu.org; 18 Feb 2014 14:31:36 +0000 Received: from localhost ([127.0.0.1]:57849 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WFlhv-0001A0-3K for submit@debbugs.gnu.org; Tue, 18 Feb 2014 09:31:35 -0500 Received: from forward6l.mail.yandex.net ([84.201.143.139]:42710) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WFlhp-00019h-Rw for 15555@debbugs.gnu.org; Tue, 18 Feb 2014 09:31:31 -0500 Received: from smtp12.mail.yandex.net (smtp12.mail.yandex.net [95.108.131.191]) by forward6l.mail.yandex.net (Yandex) with ESMTP id DE02114E1167; Tue, 18 Feb 2014 18:31:22 +0400 (MSK) Received: from smtp12.mail.yandex.net (localhost [127.0.0.1]) by smtp12.mail.yandex.net (Yandex) with ESMTP id 8974316A0138; Tue, 18 Feb 2014 18:31:22 +0400 (MSK) Received: from unknown (unknown [37.139.80.10]) by smtp12.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id yUTO2baH6P-VMI8Xd1a; Tue, 18 Feb 2014 18:31:22 +0400 (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: 2f3394d4-2e2a-4c59-85d4-6b35ec338125 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1392733882; bh=UjK8I2hkRc1CDuCcgySH6oSg8ci8vYmArxWYFpMqzPg=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=taaefuEfDlFK33nvoXliVSq4LlfvaF6+BD1NpIg7NS1TnX5aY4dQ8Mj7erxb1E61H g2ef5flVYNjOVnILjOARh5NHJX30uEd95+dlGH6ZntDm90GkZ+vUC5dCL1HQCQeGj5 NZhpWziO5Qsq95rIp3ewYRtMBH6pAgW4vulMZrNc= Authentication-Results: smtp12.mail.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <53036EBA.4060104@yandex.ru> Date: Tue, 18 Feb 2014 18:31:22 +0400 From: Dmitry Antipov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Stefan Monnier Subject: Re: bug#15555: Re: bug#15555: 24.3; Bidirectional display very slow with long lines References: <83wqlo461e.fsf@gnu.org> <8338obskk4.fsf@gnu.org> <83iox6qt1t.fsf@gnu.org> <53035588.3080705@dev.rtsoft.ru> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 15555 Cc: 15555@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) On 02/18/2014 06:04 PM, Stefan Monnier wrote: > Eli's argument is not that bidi adds its own bottlenecks, but that there > are sufficiently other bottlenecks that there's not much point trying to > address bidi's bottlenecks until we start tackling the other ones. Now I'm seeing the use case where each trivial cursor movement causes ~100 calls to bidi_shelve_cache, and each call copies ~1.5M of data. If there is a redisplay problem which makes this unavoidable without rewriting 1/2 of xdisp.c, then "broken by design" is the only thing I can say about all of that mess. Dmitry From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 18 11:21:09 2014 Received: (at 15555) by debbugs.gnu.org; 18 Feb 2014 16:21:09 +0000 Received: from localhost ([127.0.0.1]:58612 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WFnPx-0004IH-7e for submit@debbugs.gnu.org; Tue, 18 Feb 2014 11:21:09 -0500 Received: from mtaout28.012.net.il ([80.179.55.184]:39291) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WFnPv-0004HT-If for 15555@debbugs.gnu.org; Tue, 18 Feb 2014 11:21:08 -0500 Received: from conversion-daemon.mtaout28.012.net.il by mtaout28.012.net.il (HyperSendmail v2007.08) id <0N1700F0099BI400@mtaout28.012.net.il> for 15555@debbugs.gnu.org; Tue, 18 Feb 2014 18:21:46 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout28.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N17005BL9G9QPB0@mtaout28.012.net.il>; Tue, 18 Feb 2014 18:21:46 +0200 (IST) Date: Tue, 18 Feb 2014 18:21:10 +0200 From: Eli Zaretskii Subject: Re: bug#15555: 24.3; Bidirectional display very slow with long lines In-reply-to: <530367A1.3010002@yandex.ru> X-012-Sender: halo1@inter.net.il To: Dmitry Antipov Message-id: <83fvng75op.fsf@gnu.org> References: <83wqlo461e.fsf@gnu.org> <8338obskk4.fsf@gnu.org> <83iox6qt1t.fsf@gnu.org> <53035588.3080705@dev.rtsoft.ru> <530367A1.3010002@yandex.ru> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 15555 Cc: 15555@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Tue, 18 Feb 2014 18:01:05 +0400 > From: Dmitry Antipov > CC: 15555@debbugs.gnu.org > > On 02/18/2014 04:43 PM, Dmitry Antipov wrote: > > > Are you sure that bidi_copy_it doesn't add one more bottleneck to the whole > > stuff? > > There is a busy bidi_shelve_cache/bidi_unshelve_cache loop which processes > ~1.5M of cache data per each iteration. Where's that loop in the sources? > That's why memcpy takes ~25% in the overall profile... Why doesn't this happen in the other (smaller) file? From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 18 11:24:54 2014 Received: (at 15555) by debbugs.gnu.org; 18 Feb 2014 16:24:54 +0000 Received: from localhost ([127.0.0.1]:58623 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WFnTa-0004Pg-3N for submit@debbugs.gnu.org; Tue, 18 Feb 2014 11:24:54 -0500 Received: from mtaout20.012.net.il ([80.179.55.166]:38252) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WFnTY-0004PP-8I for 15555@debbugs.gnu.org; Tue, 18 Feb 2014 11:24:53 -0500 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0N1700E009JZVV00@a-mtaout20.012.net.il> for 15555@debbugs.gnu.org; Tue, 18 Feb 2014 18:24:45 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N1700EX39L9GY90@a-mtaout20.012.net.il>; Tue, 18 Feb 2014 18:24:45 +0200 (IST) Date: Tue, 18 Feb 2014 18:24:54 +0200 From: Eli Zaretskii Subject: Re: bug#15555: Re: bug#15555: 24.3; Bidirectional display very slow with long lines In-reply-to: <53036EBA.4060104@yandex.ru> X-012-Sender: halo1@inter.net.il To: Dmitry Antipov Message-id: <83eh3075ih.fsf@gnu.org> References: <83wqlo461e.fsf@gnu.org> <8338obskk4.fsf@gnu.org> <83iox6qt1t.fsf@gnu.org> <53035588.3080705@dev.rtsoft.ru> <53036EBA.4060104@yandex.ru> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 15555 Cc: 15555@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Tue, 18 Feb 2014 18:31:22 +0400 > From: Dmitry Antipov > Cc: 15555@debbugs.gnu.org > > Now I'm seeing the use case where each trivial cursor movement causes > ~100 calls to bidi_shelve_cache, and each call copies ~1.5M of data. > If there is a redisplay problem which makes this unavoidable without > rewriting 1/2 of xdisp.c, then "broken by design" is the only thing > I can say about all of that mess. If you show me where these calls are made, I might be able to say something intelligent about that. And maybe we could even discuss the issue and find some clever solution, if it exists. From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 18 12:34:58 2014 Received: (at 15555) by debbugs.gnu.org; 18 Feb 2014 17:34:58 +0000 Received: from localhost ([127.0.0.1]:58716 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WFoZO-0006Ri-6S for submit@debbugs.gnu.org; Tue, 18 Feb 2014 12:34:58 -0500 Received: from forward15.mail.yandex.net ([95.108.130.119]:56384) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WFoZK-0006R3-PG for 15555@debbugs.gnu.org; Tue, 18 Feb 2014 12:34:56 -0500 Received: from smtp14.mail.yandex.net (smtp14.mail.yandex.net [95.108.131.192]) by forward15.mail.yandex.net (Yandex) with ESMTP id 344529E2249; Tue, 18 Feb 2014 21:34:48 +0400 (MSK) Received: from smtp14.mail.yandex.net (localhost [127.0.0.1]) by smtp14.mail.yandex.net (Yandex) with ESMTP id EA8DC1B60067; Tue, 18 Feb 2014 21:34:47 +0400 (MSK) Received: from unknown (unknown [37.139.80.10]) by smtp14.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id vUTDq2q2DQ-YloO5MbP; Tue, 18 Feb 2014 21:34:47 +0400 (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: fbbb7f1d-aa68-4001-9583-987a91eb6662 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1392744887; bh=PrchcY2Oxu12LJ5cWrH3AQPBuVURyPP/qVwrPTZVxMo=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=pFXx+Qlt973w/ru1zlIix06ZzbsEbopWeFH6bEXno1AczHRSmrwWS2JSUiRBpiuLy m8vfvo6WtUNWfXDNO0NSijcu+/8juYpkgra+lGzn2qqCbZfyvoAinOczBIF5Fjl6GJ gjxhgNzTSNSgc0/LEiSzmOuUuHo4Qci+56wfopf0= Authentication-Results: smtp14.mail.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <530399B6.1090709@yandex.ru> Date: Tue, 18 Feb 2014 21:34:46 +0400 From: Dmitry Antipov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: bug#15555: Re: bug#15555: 24.3; Bidirectional display very slow with long lines References: <83wqlo461e.fsf@gnu.org> <8338obskk4.fsf@gnu.org> <83iox6qt1t.fsf@gnu.org> <53035588.3080705@dev.rtsoft.ru> <53036EBA.4060104@yandex.ru> <83eh3075ih.fsf@gnu.org> In-Reply-To: <83eh3075ih.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 15555 Cc: 15555@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 02/18/2014 08:24 PM, Eli Zaretskii wrote: > If you show me where these calls are made, I might be able to say > something intelligent about that. And maybe we could even discuss the > issue and find some clever solution, if it exists. (gdb) b bidi.c:669 ;;; at xmalloc Breakpoint 1 at 0x500890: file ../../trunk/src/bidi.c, line 669. (gdb) b bidi.c:756 ;;; at xfree Breakpoint 2 at 0x500b55: file ../../trunk/src/bidi.c, line 756. (gdb) r -Q /tmp/4000.txt In 4000.txt, eval (goto-char 2769), then press up arrow ==> Breakpoint 1, bidi_shelve_cache () at ../../trunk/src/bidi.c:669 669 databuf = xmalloc (alloc); (gdb) p alloc $1 = 292820 ;;; ~290K (gdb) bt 8 #0 bidi_shelve_cache () at ../../trunk/src/bidi.c:669 #1 0x00000000004518d2 in move_it_in_display_line_to (it=0x7fffffff9b60, to_charpos=2769, to_x=0, op=(MOVE_TO_X | MOVE_TO_POS)) at ../../trunk/src/xdisp.c:8339 #2 0x00000000004542d7 in move_it_to (it=0x7fffffff9b60, to_charpos=2769, to_x=-1, to_y=593, to_vpos=-1, op=10) at ../../trunk/src/xdisp.c:8941 #3 0x000000000043a193 in pos_visible_p (w=0x10e6518, charpos=2769, x=0x7fffffffa93c, y=0x7fffffffa938, rtop=0x7fffffffa94c, rbot=0x7fffffffa948, rowh=0x7fffffffa944, vpos=0x7fffffffa940) at ../../trunk/src/xdisp.c:1409 #4 0x00000000004aba8c in Fpos_visible_in_window_p (pos=..., window=..., partially=...) at ../../trunk/src/window.c:1812 #5 0x000000000057f82b in Fposn_at_point (pos=..., window=...) at ../../trunk/src/keyboard.c:10730 #6 0x000000000060cf02 in Ffuncall (nargs=1, args=0x7fffffffab10) at ../../trunk/src/eval.c:2818 #7 0x000000000065681f in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=2, args=0x7fffffffb3b0) at ../../trunk/src/bytecode.c:919 (More stack frames follow...) (gdb) c Continuing. Breakpoint 4, bidi_unshelve_cache (databuf=0x7fffe1a16010, just_free=true) at ../../trunk/src/bidi.c:756 756 xfree (p); etc. I can even do: (gdb) c 1000 Will ignore next 999 crossings of breakpoint 1. Continuing. Breakpoint 4, bidi_unshelve_cache (databuf=0x7fffe19ce010, just_free=true) at ../../trunk/src/bidi.c:756 756 xfree (p); and the cursor is not moved yet. Dmitry From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 18 12:42:44 2014 Received: (at 15555) by debbugs.gnu.org; 18 Feb 2014 17:42:44 +0000 Received: from localhost ([127.0.0.1]:58746 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WFogu-0006hz-1P for submit@debbugs.gnu.org; Tue, 18 Feb 2014 12:42:44 -0500 Received: from mtaout24.012.net.il ([80.179.55.180]:47887) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WFogq-0006hb-4k for 15555@debbugs.gnu.org; Tue, 18 Feb 2014 12:42:42 -0500 Received: from conversion-daemon.mtaout24.012.net.il by mtaout24.012.net.il (HyperSendmail v2007.08) id <0N1700700D2BT300@mtaout24.012.net.il> for 15555@debbugs.gnu.org; Tue, 18 Feb 2014 19:41:21 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout24.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N17004V3D4W5G00@mtaout24.012.net.il>; Tue, 18 Feb 2014 19:41:20 +0200 (IST) Date: Tue, 18 Feb 2014 19:42:41 +0200 From: Eli Zaretskii Subject: Re: bug#15555: 24.3; Bidirectional display very slow with long lines In-reply-to: <53035588.3080705@dev.rtsoft.ru> X-012-Sender: halo1@inter.net.il To: Dmitry Antipov Message-id: <838ut871wu.fsf@gnu.org> References: <83wqlo461e.fsf@gnu.org> <8338obskk4.fsf@gnu.org> <83iox6qt1t.fsf@gnu.org> <53035588.3080705@dev.rtsoft.ru> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 15555 Cc: 15555@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Tue, 18 Feb 2014 16:43:52 +0400 > From: Dmitry Antipov > CC: 15555@debbugs.gnu.org > > Hm... I have two files, with 2000 and 4000 first chars extracted from the beginning > of the monster string from http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15555#5. > > The following function: > > (defun bug15555 () > (interactive) > (while (not (eobp)) > (right-char 1) > (redisplay) > (sleep-for 0.01))) > > runs smoothly over 2000.txt, but painfully slow over 4000.txt. I'm not sure I can reproduce this. Is it possible that the difference you see between the speed of moving the cursor in these the two files is due solely to the fact that the smaller file fits completely in the window, while the larger file does not? IOW, if you enlarge the window such that the larger file is visible in its entirety, don't you see the same speed as with the smaller file? (I need about 52 lines of text in the window to show the whole of the file 4000.txt.) Likewise if you insert a R2L character at the beginning of 4000.txt, thus making its paragraph take the R2L base direction: now the cursor motion is fast even if the display needs to scroll to keep point visible, i.e. with the original window size you get in "emacs -Q". Also, the cursor movement is quite fast, and uses about 8% of a single execution unit of my Core i7, until the first time it needs to go outside the visible portion of the buffer, at which point the CPU usage of that single execution unit soars to almost 80%. If you see something different, please describe what you see. If you see what I described above, then this is a known (to me ;-) problem: when we have a continued line that takes more than 2 screen lines, and that line consists of mostly R2L characters, but the paragraph direction is L2R (or vice versa), then redisplay sometimes infloops when it needs to scroll the text in the window. The loop is not on the C level, it just causes a continuous series of re-entering redisplay, so you can stop this "infloop" by some radical cursor motion command, like C-v. This problem is hard to solve, because the code which finds a suitable window-start intrinsically assumes that the window-start position is always at column zero of the window, which is false with bidirectional text. Some of the code that is related to this needs to be redesigned to avoid this assumption. I hope to get to this some day, but since this situation is quite rare (paragraphs full of R2L characters normally have R2L base direction), this problem was never high on my todo list. > The latter case also shows the very pathological profile with ~25% > CPU spent in memcpy. > > Are you sure that bidi_copy_it doesn't add one more bottleneck to the whole > stuff? No, I don't think it does. But doing that in an infloop might ;-) Anyway, just moving cursor horizontally cannot possibly be slow due to bidi, especially as long as point stays in the same screenful. The redisplay becomes unbearably slow with long lines only when you either scroll the display (e.g., C-v) or for vertical cursor motion, because these require the display engine to traverse many buffer positions, many more than is needed to just move the cursor, and it currently can only start that traversal from the beginning of a physical line. From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 18 12:44:17 2014 Received: (at 15555) by debbugs.gnu.org; 18 Feb 2014 17:44:17 +0000 Received: from localhost ([127.0.0.1]:58749 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WFoiO-0006l3-U1 for submit@debbugs.gnu.org; Tue, 18 Feb 2014 12:44:17 -0500 Received: from mtaout26.012.net.il ([80.179.55.182]:35030) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WFoiN-0006ko-JA for 15555@debbugs.gnu.org; Tue, 18 Feb 2014 12:44:16 -0500 Received: from conversion-daemon.mtaout26.012.net.il by mtaout26.012.net.il (HyperSendmail v2007.08) id <0N1700C00CSNEG00@mtaout26.012.net.il> for 15555@debbugs.gnu.org; Tue, 18 Feb 2014 19:42:31 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout26.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N17002YAD6VVIA0@mtaout26.012.net.il>; Tue, 18 Feb 2014 19:42:31 +0200 (IST) Date: Tue, 18 Feb 2014 19:44:18 +0200 From: Eli Zaretskii Subject: Re: bug#15555: Re: bug#15555: 24.3; Bidirectional display very slow with long lines In-reply-to: X-012-Sender: halo1@inter.net.il To: Stefan Monnier Message-id: <837g8s71u5.fsf@gnu.org> References: <83wqlo461e.fsf@gnu.org> <8338obskk4.fsf@gnu.org> <83iox6qt1t.fsf@gnu.org> <53035588.3080705@dev.rtsoft.ru> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 15555 Cc: 15555@debbugs.gnu.org, antipov@dev.rtsoft.ru X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Stefan Monnier > Cc: Eli Zaretskii , 15555@debbugs.gnu.org > Date: Tue, 18 Feb 2014 09:04:56 -0500 > > > Are you sure that bidi_copy_it doesn't add one more bottleneck to the whole > > stuff? > > Eli's argument is not that bidi adds its own bottlenecks, but that there > are sufficiently other bottlenecks that there's not much point trying to > address bidi's bottlenecks until we start tackling the other ones. Yes. Basically, I claim that half of infinity is still infinity. But the situation described by Dmitry does not belong to that class of redisplay problem. From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 18 12:47:18 2014 Received: (at 15555) by debbugs.gnu.org; 18 Feb 2014 17:47:18 +0000 Received: from localhost ([127.0.0.1]:58757 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WFolJ-0006rC-K9 for submit@debbugs.gnu.org; Tue, 18 Feb 2014 12:47:18 -0500 Received: from mtaout28.012.net.il ([80.179.55.184]:44957) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WFolG-0006qr-OI for 15555@debbugs.gnu.org; Tue, 18 Feb 2014 12:47:15 -0500 Received: from conversion-daemon.mtaout28.012.net.il by mtaout28.012.net.il (HyperSendmail v2007.08) id <0N1700D00D6V0D00@mtaout28.012.net.il> for 15555@debbugs.gnu.org; Tue, 18 Feb 2014 19:47:52 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout28.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N170030SDFSRYA0@mtaout28.012.net.il>; Tue, 18 Feb 2014 19:47:52 +0200 (IST) Date: Tue, 18 Feb 2014 19:47:17 +0200 From: Eli Zaretskii Subject: Re: bug#15555: Re: bug#15555: 24.3; Bidirectional display very slow with long lines In-reply-to: <530399B6.1090709@yandex.ru> X-012-Sender: halo1@inter.net.il To: Dmitry Antipov Message-id: <8361oc71p6.fsf@gnu.org> References: <83wqlo461e.fsf@gnu.org> <8338obskk4.fsf@gnu.org> <83iox6qt1t.fsf@gnu.org> <53035588.3080705@dev.rtsoft.ru> <53036EBA.4060104@yandex.ru> <83eh3075ih.fsf@gnu.org> <530399B6.1090709@yandex.ru> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 15555 Cc: 15555@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Tue, 18 Feb 2014 21:34:46 +0400 > From: Dmitry Antipov > CC: 15555@debbugs.gnu.org > > On 02/18/2014 08:24 PM, Eli Zaretskii wrote: > > > If you show me where these calls are made, I might be able to say > > something intelligent about that. And maybe we could even discuss the > > issue and find some clever solution, if it exists. > > (gdb) b bidi.c:669 ;;; at xmalloc > Breakpoint 1 at 0x500890: file ../../trunk/src/bidi.c, line 669. > (gdb) b bidi.c:756 ;;; at xfree > Breakpoint 2 at 0x500b55: file ../../trunk/src/bidi.c, line 756. > (gdb) r -Q /tmp/4000.txt > > In 4000.txt, eval (goto-char 2769), then press up arrow ==> > > Breakpoint 1, bidi_shelve_cache () at ../../trunk/src/bidi.c:669 > 669 databuf = xmalloc (alloc); > (gdb) p alloc > $1 = 292820 ;;; ~290K > (gdb) bt 8 > #0 bidi_shelve_cache () at ../../trunk/src/bidi.c:669 > #1 0x00000000004518d2 in move_it_in_display_line_to (it=0x7fffffff9b60, to_charpos=2769, to_x=0, op=(MOVE_TO_X | MOVE_TO_POS)) > at ../../trunk/src/xdisp.c:8339 > #2 0x00000000004542d7 in move_it_to (it=0x7fffffff9b60, to_charpos=2769, to_x=-1, to_y=593, to_vpos=-1, op=10) > at ../../trunk/src/xdisp.c:8941 > #3 0x000000000043a193 in pos_visible_p (w=0x10e6518, charpos=2769, x=0x7fffffffa93c, y=0x7fffffffa938, rtop=0x7fffffffa94c, > rbot=0x7fffffffa948, rowh=0x7fffffffa944, vpos=0x7fffffffa940) at ../../trunk/src/xdisp.c:1409 > #4 0x00000000004aba8c in Fpos_visible_in_window_p (pos=..., window=..., partially=...) at ../../trunk/src/window.c:1812 > #5 0x000000000057f82b in Fposn_at_point (pos=..., window=...) at ../../trunk/src/keyboard.c:10730 > #6 0x000000000060cf02 in Ffuncall (nargs=1, args=0x7fffffffab10) at ../../trunk/src/eval.c:2818 > #7 0x000000000065681f in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=2, args=0x7fffffffb3b0) > at ../../trunk/src/bytecode.c:919 > (More stack frames follow...) > (gdb) c > Continuing. > > Breakpoint 4, bidi_unshelve_cache (databuf=0x7fffe1a16010, just_free=true) at ../../trunk/src/bidi.c:756 > 756 xfree (p); > > etc. I can even do: > > (gdb) c 1000 > Will ignore next 999 crossings of breakpoint 1. Continuing. > > Breakpoint 4, bidi_unshelve_cache (databuf=0x7fffe19ce010, just_free=true) at ../../trunk/src/bidi.c:756 > 756 xfree (p); > > and the cursor is not moved yet. Thanks. That's the "infloop" I described in my other message. It should disappear if you try one of the "remedies" I described there. From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 18 12:58:18 2014 Received: (at 15555) by debbugs.gnu.org; 18 Feb 2014 17:58:18 +0000 Received: from localhost ([127.0.0.1]:58773 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WFovx-0007AN-BE for submit@debbugs.gnu.org; Tue, 18 Feb 2014 12:58:17 -0500 Received: from mtaout26.012.net.il ([80.179.55.182]:46008) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WFovu-0007A2-PS for 15555@debbugs.gnu.org; Tue, 18 Feb 2014 12:58:15 -0500 Received: from conversion-daemon.mtaout26.012.net.il by mtaout26.012.net.il (HyperSendmail v2007.08) id <0N1700H00DPMAA00@mtaout26.012.net.il> for 15555@debbugs.gnu.org; Tue, 18 Feb 2014 19:56:30 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout26.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N1700EDQDU6HK30@mtaout26.012.net.il>; Tue, 18 Feb 2014 19:56:30 +0200 (IST) Date: Tue, 18 Feb 2014 19:58:17 +0200 From: Eli Zaretskii Subject: Re: bug#15555: Re: bug#15555: 24.3; Bidirectional display very slow with long lines In-reply-to: <53036EBA.4060104@yandex.ru> X-012-Sender: halo1@inter.net.il To: Dmitry Antipov Message-id: <834n3w716u.fsf@gnu.org> References: <83wqlo461e.fsf@gnu.org> <8338obskk4.fsf@gnu.org> <83iox6qt1t.fsf@gnu.org> <53035588.3080705@dev.rtsoft.ru> <53036EBA.4060104@yandex.ru> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 15555 Cc: 15555@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Tue, 18 Feb 2014 18:31:22 +0400 > From: Dmitry Antipov > Cc: 15555@debbugs.gnu.org > > Now I'm seeing the use case where each trivial cursor movement causes > ~100 calls to bidi_shelve_cache, and each call copies ~1.5M of data. Is this still the same use case with your bug15555 function and the 4000.txt file? If not, please describe this use case. As for calls to bidi_shelve_cache, they are a side effect of saving and restoring the iterator object, see the commentary before the definition of the SAVE_IT macro. From debbugs-submit-bounces@debbugs.gnu.org Wed Feb 19 00:48:34 2014 Received: (at 15555) by debbugs.gnu.org; 19 Feb 2014 05:48:34 +0000 Received: from localhost ([127.0.0.1]:59344 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WG01J-00066W-GZ for submit@debbugs.gnu.org; Wed, 19 Feb 2014 00:48:33 -0500 Received: from forward5l.mail.yandex.net ([84.201.143.138]:38713) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WG01G-00066C-HI for 15555@debbugs.gnu.org; Wed, 19 Feb 2014 00:48:31 -0500 Received: from smtp11.mail.yandex.net (smtp11.mail.yandex.net [95.108.130.67]) by forward5l.mail.yandex.net (Yandex) with ESMTP id E81D1C40E4D; Wed, 19 Feb 2014 09:48:21 +0400 (MSK) Received: from smtp11.mail.yandex.net (localhost [127.0.0.1]) by smtp11.mail.yandex.net (Yandex) with ESMTP id 953407E0883; Wed, 19 Feb 2014 09:48:21 +0400 (MSK) Received: from unknown (unknown [37.139.80.10]) by smtp11.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id 4O2ujzWn3X-mLhq8Y0R; Wed, 19 Feb 2014 09:48:21 +0400 (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: a6b837c4-a214-494c-8bdc-79d4cde4a11f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1392788901; bh=1HvdMn0PwQGi3mST0vPxpk3M/vKlZCAc0MhxCtrDgQw=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type; b=jPo0gLKJyKvcDMxvEXZoxjGvkiyKyKGjnKEdNlXBjD6K+pd1ulPb343ds/+kCSAmC hZiE8nRRb317d3/aI2AaGlmL+FR8Z5MpoRb45gEU/7hEVZEtJdh7ScANezGW3LfFte U/407dyB6S6E+1CB1VmSHK9OJj5qjUqSN+ZlQ8M0= Authentication-Results: smtp11.mail.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <530445A5.1030506@yandex.ru> Date: Wed, 19 Feb 2014 09:48:21 +0400 From: Dmitry Antipov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: bug#15555: Re: bug#15555: 24.3; Bidirectional display very slow with long lines References: <83wqlo461e.fsf@gnu.org> <8338obskk4.fsf@gnu.org> <83iox6qt1t.fsf@gnu.org> <53035588.3080705@dev.rtsoft.ru> <53036EBA.4060104@yandex.ru> <834n3w716u.fsf@gnu.org> In-Reply-To: <834n3w716u.fsf@gnu.org> Content-Type: multipart/mixed; boundary="------------060702010409060506010904" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 15555 Cc: 15555@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) This is a multi-part message in MIME format. --------------060702010409060506010904 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 02/18/2014 09:58 PM, Eli Zaretskii wrote: > Is this still the same use case with your bug15555 function and the > 4000.txt file? If not, please describe this use case. Yes. There is a simple patch to trace bidi_shelve_cache/bidi_unshelve_cache and two screencasts, with bug15555 over 2000.txt [1] and 4000.txt [2], respectively. [1] http://37.139.80.10/tmp/2000.mkv [2] http://37.139.80.10/tmp/4000.mkv Dmitry --------------060702010409060506010904 Content-Type: text/x-patch; name="trace_bug15555.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="trace_bug15555.patch" === modified file 'src/bidi.c' --- src/bidi.c 2014-01-01 17:44:48 +0000 +++ src/bidi.c 2014-02-19 04:07:08 +0000 @@ -62,6 +62,7 @@ #include "buffer.h" #include "dispextern.h" #include "region-cache.h" +#include "systime.h" static bool bidi_initialized = 0; @@ -668,6 +669,8 @@ + bidi_cache_idx * sizeof (struct bidi_it)); databuf = xmalloc (alloc); bidi_cache_total_alloc += alloc; + fprintf (stderr, "%s [%f]: alloc %"pI"d bytes -> %p\n", __func__, + timespectod (current_timespec ()), alloc, databuf); memcpy (databuf, &bidi_cache_idx, sizeof (bidi_cache_idx)); memcpy (databuf + sizeof (bidi_cache_idx), @@ -752,6 +755,8 @@ -= (bidi_shelve_header_size + bidi_cache_idx * sizeof (struct bidi_it)); } + fprintf (stderr, "%s [%f]: free %p\n", __func__, + timespectod (current_timespec ()), databuf); xfree (p); } --------------060702010409060506010904-- From debbugs-submit-bounces@debbugs.gnu.org Wed Feb 19 05:49:50 2014 Received: (at 15555) by debbugs.gnu.org; 19 Feb 2014 10:49:50 +0000 Received: from localhost ([127.0.0.1]:59539 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WG4ir-0007KZ-Db for submit@debbugs.gnu.org; Wed, 19 Feb 2014 05:49:49 -0500 Received: from forward5l.mail.yandex.net ([84.201.143.138]:59108) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WG4io-0007KL-Jz for 15555@debbugs.gnu.org; Wed, 19 Feb 2014 05:49:47 -0500 Received: from smtp13.mail.yandex.net (smtp13.mail.yandex.net [95.108.130.68]) by forward5l.mail.yandex.net (Yandex) with ESMTP id E2779C40F52; Wed, 19 Feb 2014 14:49:39 +0400 (MSK) Received: from smtp13.mail.yandex.net (localhost [127.0.0.1]) by smtp13.mail.yandex.net (Yandex) with ESMTP id 8B04FE4012F; Wed, 19 Feb 2014 14:49:39 +0400 (MSK) Received: from unknown (unknown [37.139.80.10]) by smtp13.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id 5h4tKZlPVe-ndk0AApS; Wed, 19 Feb 2014 14:49:39 +0400 (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: 64b9f98d-7f40-4ee0-8d03-b25983400b2f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1392806979; bh=5W8vJwduD8NJl1yNpMH7IZwuq7W7W6iehchcvOUfrkU=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=ZcuYJT0yanml5fMXnZNKw3gTP1G7QfWFgOMc0M0WfzDEeK/NUeiCNf2lDVQTYgHob dGP/3VORteLDoDWLoMyn+Oc0x1CKmMc8bhxGNXDmNyP2/6NeNnvqqwy6sDz2q5rjPQ xTIfL4Dyb5FdcBc3/YackulFpF8zW/GcSSohrXGo= Authentication-Results: smtp13.mail.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <53048C43.7090304@yandex.ru> Date: Wed, 19 Feb 2014 14:49:39 +0400 From: Dmitry Antipov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: Re: bug#15555: 24.3; Bidirectional display very slow with long lines References: <83wqlo461e.fsf@gnu.org> <8338obskk4.fsf@gnu.org> <83iox6qt1t.fsf@gnu.org> <53035588.3080705@dev.rtsoft.ru> <838ut871wu.fsf@gnu.org> In-Reply-To: <838ut871wu.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 15555 Cc: 15555@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) On 02/18/2014 09:42 PM, Eli Zaretskii wrote: > Anyway, just moving cursor horizontally cannot possibly be slow due to > bidi, especially as long as point stays in the same screenful. The > redisplay becomes unbearably slow with long lines only when you either > scroll the display (e.g., C-v) or for vertical cursor motion, because > these require the display engine to traverse many buffer positions, > many more than is needed to just move the cursor, and it currently can > only start that traversal from the beginning of a physical line. 1) I realize that vertical motion is slower than horizontal, but [2] from http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15555#65 shows that the major slowdown happens when cursor is moved horizontally (by right-char) within the same line. 2) (setq bidi-display-reordering nil) helps bug15555 to run over 4000.txt just as expected. Dmitry From debbugs-submit-bounces@debbugs.gnu.org Wed Feb 19 12:36:42 2014 Received: (at 15555) by debbugs.gnu.org; 19 Feb 2014 17:36:42 +0000 Received: from localhost ([127.0.0.1]:60513 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WGB4c-00037l-Bs for submit@debbugs.gnu.org; Wed, 19 Feb 2014 12:36:42 -0500 Received: from mtaout24.012.net.il ([80.179.55.180]:44775) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WGB4Z-00037S-Fb for 15555@debbugs.gnu.org; Wed, 19 Feb 2014 12:36:40 -0500 Received: from conversion-daemon.mtaout24.012.net.il by mtaout24.012.net.il (HyperSendmail v2007.08) id <0N1900C007GTBU00@mtaout24.012.net.il> for 15555@debbugs.gnu.org; Wed, 19 Feb 2014 19:35:19 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout24.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N19005YW7IUK170@mtaout24.012.net.il>; Wed, 19 Feb 2014 19:35:18 +0200 (IST) Date: Wed, 19 Feb 2014 19:36:44 +0200 From: Eli Zaretskii Subject: Re: bug#15555: 24.3; Bidirectional display very slow with long lines In-reply-to: <530445A5.1030506@yandex.ru> X-012-Sender: halo1@inter.net.il To: Dmitry Antipov Message-id: <83eh2z57ir.fsf@gnu.org> References: <83wqlo461e.fsf@gnu.org> <8338obskk4.fsf@gnu.org> <83iox6qt1t.fsf@gnu.org> <53035588.3080705@dev.rtsoft.ru> <53036EBA.4060104@yandex.ru> <834n3w716u.fsf@gnu.org> <530445A5.1030506@yandex.ru> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 15555 Cc: 15555@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Wed, 19 Feb 2014 09:48:21 +0400 > From: Dmitry Antipov > CC: 15555@debbugs.gnu.org > > There is a simple patch to trace bidi_shelve_cache/bidi_unshelve_cache and > two screencasts, with bug15555 over 2000.txt [1] and 4000.txt [2], respectively. > > [1] http://37.139.80.10/tmp/2000.mkv > [2] http://37.139.80.10/tmp/4000.mkv I cannot play MKV files here, sorry. Do they show something different from what I described? From debbugs-submit-bounces@debbugs.gnu.org Wed Feb 19 12:39:58 2014 Received: (at 15555) by debbugs.gnu.org; 19 Feb 2014 17:39:58 +0000 Received: from localhost ([127.0.0.1]:60517 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WGB7l-0003Es-WA for submit@debbugs.gnu.org; Wed, 19 Feb 2014 12:39:58 -0500 Received: from mtaout20.012.net.il ([80.179.55.166]:49263) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WGB7h-0003Ec-Lr for 15555@debbugs.gnu.org; Wed, 19 Feb 2014 12:39:54 -0500 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0N19006007N9QZ00@a-mtaout20.012.net.il> for 15555@debbugs.gnu.org; Wed, 19 Feb 2014 19:39:47 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N19006JO7Q9LJ40@a-mtaout20.012.net.il>; Wed, 19 Feb 2014 19:39:46 +0200 (IST) Date: Wed, 19 Feb 2014 19:39:57 +0200 From: Eli Zaretskii Subject: Re: bug#15555: 24.3; Bidirectional display very slow with long lines In-reply-to: <53048C43.7090304@yandex.ru> X-012-Sender: halo1@inter.net.il To: Dmitry Antipov Message-id: <83d2ij57de.fsf@gnu.org> References: <83wqlo461e.fsf@gnu.org> <8338obskk4.fsf@gnu.org> <83iox6qt1t.fsf@gnu.org> <53035588.3080705@dev.rtsoft.ru> <838ut871wu.fsf@gnu.org> <53048C43.7090304@yandex.ru> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 15555 Cc: 15555@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Wed, 19 Feb 2014 14:49:39 +0400 > From: Dmitry Antipov > CC: 15555@debbugs.gnu.org > > On 02/18/2014 09:42 PM, Eli Zaretskii wrote: > > > Anyway, just moving cursor horizontally cannot possibly be slow due to > > bidi, especially as long as point stays in the same screenful. The > > redisplay becomes unbearably slow with long lines only when you either > > scroll the display (e.g., C-v) or for vertical cursor motion, because > > these require the display engine to traverse many buffer positions, > > many more than is needed to just move the cursor, and it currently can > > only start that traversal from the beginning of a physical line. > > 1) I realize that vertical motion is slower than horizontal, but [2] from > http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15555#65 shows that the major > slowdown happens when cursor is moved horizontally (by right-char) within > the same line. According to the value of point that you gave, this happens when the next buffer position, the one where right-char should move, is beyond the window, i.e. not on the same screen line. Did you try enlarging the window so that the entire text of 4000.txt fits in the window? Do you still see slow cursor movement in that case? > 2) (setq bidi-display-reordering nil) helps bug15555 to run over 4000.txt > just as expected. Of course, because then the bug I described, which causes endless re-entering of redisplay, doesn't happen. IOW, this is a bug in that specific situation, not a slow-down. From debbugs-submit-bounces@debbugs.gnu.org Wed Feb 19 12:43:06 2014 Received: (at 15555) by debbugs.gnu.org; 19 Feb 2014 17:43:06 +0000 Received: from localhost ([127.0.0.1]:60521 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WGBAn-0003KY-JY for submit@debbugs.gnu.org; Wed, 19 Feb 2014 12:43:06 -0500 Received: from mtaout25.012.net.il ([80.179.55.181]:47630) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WGBAl-0003Jy-GR for 15555@debbugs.gnu.org; Wed, 19 Feb 2014 12:43:04 -0500 Received: from conversion-daemon.mtaout25.012.net.il by mtaout25.012.net.il (HyperSendmail v2007.08) id <0N19005007NKQ300@mtaout25.012.net.il> for 15555@debbugs.gnu.org; Wed, 19 Feb 2014 19:41:42 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout25.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N190060Z7TIPD00@mtaout25.012.net.il>; Wed, 19 Feb 2014 19:41:42 +0200 (IST) Date: Wed, 19 Feb 2014 19:43:08 +0200 From: Eli Zaretskii Subject: Re: bug#15555: Re: bug#15555: 24.3; Bidirectional display very slow with long lines In-reply-to: <530399B6.1090709@yandex.ru> X-012-Sender: halo1@inter.net.il To: Dmitry Antipov Message-id: <83bny35783.fsf@gnu.org> References: <83wqlo461e.fsf@gnu.org> <8338obskk4.fsf@gnu.org> <83iox6qt1t.fsf@gnu.org> <53035588.3080705@dev.rtsoft.ru> <53036EBA.4060104@yandex.ru> <83eh3075ih.fsf@gnu.org> <530399B6.1090709@yandex.ru> X-Spam-Score: 3.7 (+++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > Date: Tue, 18 Feb 2014 21:34:46 +0400 > From: Dmitry Antipov > CC: 15555@debbugs.gnu.org > > (gdb) b bidi.c:669 ;;; at xmalloc > Breakpoint 1 at 0x500890: file ../../trunk/src/bidi.c, line 669. > (gdb) b bidi.c:756 ; ; ; at xfree > Breakpoint 2 at 0x500b55: file ../../trunk/src/bidi.c, line 756. > (gdb) r -Q /tmp/4000.txt > > In 4000.txt, eval (goto-char 2769), then press up arrow ==> > > Breakpoint 1, bidi_shelve_cache () at ../../trunk/src/bidi.c:669 > 669 databuf = xmalloc (alloc); > (gdb) p alloc > $1 = 292820 ;;; ~290K [...] Content analysis details: (3.7 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 2.7 RCVD_IN_PSBL RBL: Received via a relay in PSBL [80.179.55.181 listed in psbl.surriel.com] 1.0 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) X-Debbugs-Envelope-To: 15555 Cc: 15555@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 3.7 (+++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > Date: Tue, 18 Feb 2014 21:34:46 +0400 > From: Dmitry Antipov > CC: 15555@debbugs.gnu.org > > (gdb) b bidi.c:669 ;;; at xmalloc > Breakpoint 1 at 0x500890: file ../../trunk/src/bidi.c, line 669. > (gdb) b bidi.c:756 ;;; at xfree > Breakpoint 2 at 0x500b55: file ../../trunk/src/bidi.c, line 756. > (gdb) r -Q /tmp/4000.txt > > In 4000.txt, eval (goto-char 2769), then press up arrow ==> > > Breakpoint 1, bidi_shelve_cache () at ../../trunk/src/bidi.c:669 > 669 databuf = xmalloc (alloc); > (gdb) p alloc > $1 = 292820 ;;; ~290K [...] Content analysis details: (3.7 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 2.7 RCVD_IN_PSBL RBL: Received via a relay in PSBL [80.179.55.181 listed in psbl.surriel.com] 1.0 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) > Date: Tue, 18 Feb 2014 21:34:46 +0400 > From: Dmitry Antipov > CC: 15555@debbugs.gnu.org > > (gdb) b bidi.c:669 ;;; at xmalloc > Breakpoint 1 at 0x500890: file ../../trunk/src/bidi.c, line 669. > (gdb) b bidi.c:756 ;;; at xfree > Breakpoint 2 at 0x500b55: file ../../trunk/src/bidi.c, line 756. > (gdb) r -Q /tmp/4000.txt > > In 4000.txt, eval (goto-char 2769), then press up arrow ==> > > Breakpoint 1, bidi_shelve_cache () at ../../trunk/src/bidi.c:669 > 669 databuf = xmalloc (alloc); > (gdb) p alloc > $1 = 292820 ;;; ~290K That's 290K, not 1.5M. But even 1.5M should take about 100 usec to move with memcpy. So this is not a catastrophe. Of course, doing this in a never-ending loop is not nice, but that's not a slowdown, that's a bug. From debbugs-submit-bounces@debbugs.gnu.org Thu Feb 20 02:22:01 2014 Received: (at 15555) by debbugs.gnu.org; 20 Feb 2014 07:22:01 +0000 Received: from localhost ([127.0.0.1]:32971 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WGNxI-0001DA-Kc for submit@debbugs.gnu.org; Thu, 20 Feb 2014 02:22:01 -0500 Received: from forward12.mail.yandex.net ([95.108.130.94]:57383) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WGNxF-0001Ct-6x for 15555@debbugs.gnu.org; Thu, 20 Feb 2014 02:21:58 -0500 Received: from smtp13.mail.yandex.net (smtp13.mail.yandex.net [95.108.130.68]) by forward12.mail.yandex.net (Yandex) with ESMTP id 76462C21A8C; Thu, 20 Feb 2014 11:21:50 +0400 (MSK) Received: from smtp13.mail.yandex.net (localhost [127.0.0.1]) by smtp13.mail.yandex.net (Yandex) with ESMTP id 3BC1CE40097; Thu, 20 Feb 2014 11:21:50 +0400 (MSK) Received: from unknown (unknown [37.139.80.10]) by smtp13.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id xPBuQGScL2-LncCeCMR; Thu, 20 Feb 2014 11:21:49 +0400 (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: 10b386a0-187a-4818-b2d2-3a26579f21a1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1392880909; bh=RMNA7CnXWnmdfdjM2drhFdYQCKi7PCwBSK0amh9gBIY=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=cv+7R3vXhpZpspElrYr7Ns3XZ2/4SQe9MwvRPZPoZeS7+fDNFYiIdAbmyLS073O8g vQxoH3WaK8dsHJEJclXm/VFR3sky/iSctrui9D8N+PjWQ8S2GdyeXhjlSSxtt0gI34 ElKtDa0KPN/aYmO5i4DjA109G34tE9LsQLBEVdwY= Authentication-Results: smtp13.mail.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <5305AD0D.7040904@yandex.ru> Date: Thu, 20 Feb 2014 11:21:49 +0400 From: Dmitry Antipov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: bug#15555: 24.3; Bidirectional display very slow with long lines References: <83wqlo461e.fsf@gnu.org> <8338obskk4.fsf@gnu.org> <83iox6qt1t.fsf@gnu.org> <53035588.3080705@dev.rtsoft.ru> <838ut871wu.fsf@gnu.org> <53048C43.7090304@yandex.ru> <83d2ij57de.fsf@gnu.org> In-Reply-To: <83d2ij57de.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 15555 Cc: 15555@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 02/19/2014 09:39 PM, Eli Zaretskii wrote: > According to the value of point that you gave, this happens when the > next buffer position, the one where right-char should move, is beyond > the window, i.e. not on the same screen line. > > Did you try enlarging the window so that the entire text of 4000.txt > fits in the window? Do you still see slow cursor movement in that > case? When I toggle fullscreen and the whole text fits in the window, it works smoothly as with 2000.txt example. Dmitry From debbugs-submit-bounces@debbugs.gnu.org Thu Feb 20 02:32:42 2014 Received: (at 15555) by debbugs.gnu.org; 20 Feb 2014 07:32:42 +0000 Received: from localhost ([127.0.0.1]:32984 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WGO7d-0001Vs-Ky for submit@debbugs.gnu.org; Thu, 20 Feb 2014 02:32:42 -0500 Received: from forward15.mail.yandex.net ([95.108.130.119]:60532) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WGO7a-0001VZ-U8 for 15555@debbugs.gnu.org; Thu, 20 Feb 2014 02:32:39 -0500 Received: from smtp11.mail.yandex.net (smtp11.mail.yandex.net [95.108.130.67]) by forward15.mail.yandex.net (Yandex) with ESMTP id 6C7599E1AB0; Thu, 20 Feb 2014 11:32:32 +0400 (MSK) Received: from smtp11.mail.yandex.net (localhost [127.0.0.1]) by smtp11.mail.yandex.net (Yandex) with ESMTP id 2DE627E0883; Thu, 20 Feb 2014 11:32:32 +0400 (MSK) Received: from unknown (unknown [37.139.80.10]) by smtp11.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id kGQQ3gsnGH-WV1upYtp; Thu, 20 Feb 2014 11:32:31 +0400 (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: 4c3f2ddf-ab2e-47d8-8f8b-304396996ded DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1392881551; bh=0Jj9cRNjQk4KxjfUR9i80qiudG3a1xZE4tOJqKJBg1A=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=nHjbczXc6+BcjuwMBEwPiEd0bu2AcIyjxt5yBK+5saJRXmWUI40vdYNIQGvDzsfQc 8yRljcNPm9MP/LeabpP43Gb6XcNJ7KH0xNDT5BAQ7lKbS4JD3TBy6pFZpprcqBKAa+ KVrzKWuLOPAeKa0+qP764OdNX5MqS1FbHxDJqE7g= Authentication-Results: smtp11.mail.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <5305AF8F.6080809@yandex.ru> Date: Thu, 20 Feb 2014 11:32:31 +0400 From: Dmitry Antipov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: bug#15555: Re: bug#15555: 24.3; Bidirectional display very slow with long lines References: <83wqlo461e.fsf@gnu.org> <8338obskk4.fsf@gnu.org> <83iox6qt1t.fsf@gnu.org> <53035588.3080705@dev.rtsoft.ru> <53036EBA.4060104@yandex.ru> <83eh3075ih.fsf@gnu.org> <530399B6.1090709@yandex.ru> <83bny35783.fsf@gnu.org> In-Reply-To: <83bny35783.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 15555 Cc: 15555@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 02/19/2014 09:43 PM, Eli Zaretskii wrote: > That's 290K, not 1.5M. But even 1.5M should take about 100 usec to > move with memcpy. So this is not a catastrophe. Even if it happens 1000 times per second? If 190M doesn't bother you, it's still worth to see at http://37.139.80.10/tmp/4000.avi. Dmitry From debbugs-submit-bounces@debbugs.gnu.org Thu Feb 20 12:44:14 2014 Received: (at 15555) by debbugs.gnu.org; 20 Feb 2014 17:44:14 +0000 Received: from localhost ([127.0.0.1]:33887 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WGXfS-0002yh-BQ for submit@debbugs.gnu.org; Thu, 20 Feb 2014 12:44:14 -0500 Received: from mtaout28.012.net.il ([80.179.55.184]:45573) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WGXfN-0002yE-IB for 15555@debbugs.gnu.org; Thu, 20 Feb 2014 12:44:10 -0500 Received: from conversion-daemon.mtaout28.012.net.il by mtaout28.012.net.il (HyperSendmail v2007.08) id <0N1B0020028F9N00@mtaout28.012.net.il> for 15555@debbugs.gnu.org; Thu, 20 Feb 2014 19:44:42 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout28.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N1B0007F2MIRK30@mtaout28.012.net.il>; Thu, 20 Feb 2014 19:44:42 +0200 (IST) Date: Thu, 20 Feb 2014 19:44:17 +0200 From: Eli Zaretskii Subject: Re: bug#15555: Re: bug#15555: 24.3; Bidirectional display very slow with long lines In-reply-to: <53036EBA.4060104@yandex.ru> X-012-Sender: halo1@inter.net.il To: Dmitry Antipov Message-id: <83y5154r2m.fsf@gnu.org> References: <83wqlo461e.fsf@gnu.org> <8338obskk4.fsf@gnu.org> <83iox6qt1t.fsf@gnu.org> <53035588.3080705@dev.rtsoft.ru> <53036EBA.4060104@yandex.ru> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 15555 Cc: 15555@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Tue, 18 Feb 2014 18:31:22 +0400 > From: Dmitry Antipov > Cc: 15555@debbugs.gnu.org > > Now I'm seeing the use case where each trivial cursor movement causes > ~100 calls to bidi_shelve_cache, and each call copies ~1.5M of data. Starting with revision 116494, bidi_shelve_cache should be called much less, normally just once and sometimes twice per call to move_it_in_display_line_to. This doesn't solve the original bug, so the cursor will occasionally still get stuck in that 4000.txt file, but at least it will do that with much less noise. From debbugs-submit-bounces@debbugs.gnu.org Thu Feb 20 12:45:13 2014 Received: (at 15555) by debbugs.gnu.org; 20 Feb 2014 17:45:14 +0000 Received: from localhost ([127.0.0.1]:33895 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WGXgP-00031I-Bq for submit@debbugs.gnu.org; Thu, 20 Feb 2014 12:45:13 -0500 Received: from mtaout21.012.net.il ([80.179.55.169]:52945) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WGXgM-00030z-Gl for 15555@debbugs.gnu.org; Thu, 20 Feb 2014 12:45:11 -0500 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0N1B00E0026ZIW00@a-mtaout21.012.net.il> for 15555@debbugs.gnu.org; Thu, 20 Feb 2014 19:45:04 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N1B00EOR2N3A390@a-mtaout21.012.net.il>; Thu, 20 Feb 2014 19:45:04 +0200 (IST) Date: Thu, 20 Feb 2014 19:45:18 +0200 From: Eli Zaretskii Subject: Re: bug#15555: Re: bug#15555: 24.3; Bidirectional display very slow with long lines In-reply-to: <5305AF8F.6080809@yandex.ru> X-012-Sender: halo1@inter.net.il To: Dmitry Antipov Message-id: <83wqgp4r0x.fsf@gnu.org> References: <83wqlo461e.fsf@gnu.org> <8338obskk4.fsf@gnu.org> <83iox6qt1t.fsf@gnu.org> <53035588.3080705@dev.rtsoft.ru> <53036EBA.4060104@yandex.ru> <83eh3075ih.fsf@gnu.org> <530399B6.1090709@yandex.ru> <83bny35783.fsf@gnu.org> <5305AF8F.6080809@yandex.ru> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 15555 Cc: 15555@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Thu, 20 Feb 2014 11:32:31 +0400 > From: Dmitry Antipov > CC: 15555@debbugs.gnu.org > > On 02/19/2014 09:43 PM, Eli Zaretskii wrote: > > > That's 290K, not 1.5M. But even 1.5M should take about 100 usec to > > move with memcpy. So this is not a catastrophe. > > Even if it happens 1000 times per second? > > If 190M doesn't bother you, it's still worth > to see at http://37.139.80.10/tmp/4000.avi. Does it look better now? From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 21 00:32:17 2014 Received: (at 15555) by debbugs.gnu.org; 21 Feb 2014 05:32:17 +0000 Received: from localhost ([127.0.0.1]:34187 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WGiie-0006Fw-CS for submit@debbugs.gnu.org; Fri, 21 Feb 2014 00:32:16 -0500 Received: from forward10l.mail.yandex.net ([84.201.143.143]:59608) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WGiib-0006Fh-HQ for 15555@debbugs.gnu.org; Fri, 21 Feb 2014 00:32:14 -0500 Received: from smtp4h.mail.yandex.net (smtp4h.mail.yandex.net [84.201.186.21]) by forward10l.mail.yandex.net (Yandex) with ESMTP id CF198BA0F1D; Fri, 21 Feb 2014 09:32:06 +0400 (MSK) Received: from smtp4h.mail.yandex.net (localhost [127.0.0.1]) by smtp4h.mail.yandex.net (Yandex) with ESMTP id 747172C3440; Fri, 21 Feb 2014 09:32:06 +0400 (MSK) Received: from unknown (unknown [37.139.80.10]) by smtp4h.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id R58w2BGjmW-W6DSsA9B; Fri, 21 Feb 2014 09:32:06 +0400 (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: 289ed72c-d43d-4d9a-8b3b-8727d57696df DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1392960726; bh=AN1r1gQWzlDoMum7dD7xIhFAzEHN290O9DHfMl4uoSA=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=XvnwSvnGZ387xQWTtlpDilSQZGp5H88net9Bk0bYgvaEdqiDg6tm7LBKSWIi0bhKR BG3vjyCYvtzSJcSv1Z2JQP6chLGl5kAW7fxGIk0TahaoUFYcPMN9HiWbpKoRm3/M0c ywmObrE2R/+jmmD7kY0DqkHj4khzSv2Q493MsT7g= Authentication-Results: smtp4h.mail.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <5306E4D6.7060801@yandex.ru> Date: Fri, 21 Feb 2014 09:32:06 +0400 From: Dmitry Antipov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: bug#15555: Re: bug#15555: 24.3; Bidirectional display very slow with long lines References: <83wqlo461e.fsf@gnu.org> <8338obskk4.fsf@gnu.org> <83iox6qt1t.fsf@gnu.org> <53035588.3080705@dev.rtsoft.ru> <53036EBA.4060104@yandex.ru> <83eh3075ih.fsf@gnu.org> <530399B6.1090709@yandex.ru> <83bny35783.fsf@gnu.org> <5305AF8F.6080809@yandex.ru> <83wqgp4r0x.fsf@gnu.org> In-Reply-To: <83wqgp4r0x.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 15555 Cc: 15555@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) On 02/20/2014 09:45 PM, Eli Zaretskii wrote: > Does it look better now? Definitely. Thanks. Dmitry From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 23 05:50:50 2014 Received: (at control) by debbugs.gnu.org; 23 Sep 2014 09:50:50 +0000 Received: from localhost ([127.0.0.1]:49447 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XWMkE-00087q-2G for submit@debbugs.gnu.org; Tue, 23 Sep 2014 05:50:50 -0400 Received: from fencepost.gnu.org ([208.118.235.10]:53023) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XWMkB-00087i-Qy for control@debbugs.gnu.org; Tue, 23 Sep 2014 05:50:48 -0400 Received: from rgm by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1XWMkB-0006wu-Kk for control@debbugs.gnu.org; Tue, 23 Sep 2014 05:50:47 -0400 Date: Tue, 23 Sep 2014 05:50:47 -0400 Message-Id: Subject: control message for bug 18530 To: X-Mailer: mail (GNU Mailutils 2.1) From: Glenn Morris X-Spam-Score: -6.0 (------) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.0 (------) merge 3219 18530 From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 26 00:13:11 2016 Received: (at 15555) by debbugs.gnu.org; 26 Jan 2016 05:13:11 +0000 Received: from localhost ([127.0.0.1]:36523 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aNvwE-0001bE-VZ for submit@debbugs.gnu.org; Tue, 26 Jan 2016 00:13:11 -0500 Received: from mail-qg0-f46.google.com ([209.85.192.46]:35514) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aNvwD-0001ay-Dw; Tue, 26 Jan 2016 00:13:09 -0500 Received: by mail-qg0-f46.google.com with SMTP id o11so127228351qge.2; Mon, 25 Jan 2016 21:13:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=+Kbp4D7VE6ZBdexfiVOBTNwi2sWi6i7dCgZNwp1MIWc=; b=u8PknroAF8cIR1/+MUP1XwCVDuLTLUTM6gVDntq3+YJ6WtkdaT5bxQHZSx17JyxOx6 hBCN1KMGP6weKQzzTiSpqZHfP2h0EoZS7VPd2a2D0w3gCnmxqtzXY3cvM/8Trk40D85W SZ1CDGdsNvB9YZ6Kee1JdvTra2ElPtJ4aKWTOwcsM03niQVAcJSJU8t5AUA7/WwUC4uj jFSmvaPMn0tRFBdBwebVCOkGquWU2rvaH0oOkJRvtp9Z1f9pEroESICSTVoHoct7PhyD GvI/GBkcGZxn7YWOORMqb1kaFstCNlxWnZ4nL0yge2Kjhow2OHcoTbhFIHAT6Su0+vvd 4sBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=+Kbp4D7VE6ZBdexfiVOBTNwi2sWi6i7dCgZNwp1MIWc=; b=kmxScOrxR+MTGo2FW5ihArbe7WlmcpkA0Z8wtUhmQ0l4VI6jvYS+n1XQ88LsI131vq CywDEwq9cEUxXZw5J9k7LXy8tdwYtNPp2ZKD6sWTBjXo0fGMpK4StLydxPqufUEeAGAw IO/Q3a+PNmQP78sOpUtsT8ceCtmZFWNR1Vn8n2cs2/OGi2opILsMeMwLqPGzUycqJjD4 m3XG9erKY/DcYbcdT9iZv5eAPgwTBVEIrM4YtImGhZeaJaOCPj4dYByzHkTEe1MdE6oY hRd8IAFm7/7Cgfebg5j4AtdLpdG95GpxjT/gIVxeozqKejUuoBjHw/TR3Ssylw2W/eGa /JOQ== X-Gm-Message-State: AG10YORE6Wtwe8aozytMmj/Wl91Zp98I+sOCVfUFe+hJM+VLg1inhB+9WJi5INMWle84HQ== X-Received: by 10.55.80.131 with SMTP id e125mr25892105qkb.62.1453785184077; Mon, 25 Jan 2016 21:13:04 -0800 (PST) Received: from Andrews-MacBook-Pro.local.ahyatt-laptop (cpe-74-73-128-199.nyc.res.rr.com. [74.73.128.199]) by smtp.gmail.com with ESMTPSA id g6sm10195784qgd.5.2016.01.25.21.13.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Jan 2016 21:13:03 -0800 (PST) From: Andrew Hyatt To: Jerome L Quinn Subject: Re: bug#15555: 24.3; Bidirectional display very slow with long lines References: <83wqlo461e.fsf@gnu.org> <8338obskk4.fsf@gnu.org> <83iox6qt1t.fsf@gnu.org> Date: Tue, 26 Jan 2016 00:13:01 -0500 In-Reply-To: (Jerome L. Quinn's message of "Wed, 9 Oct 2013 14:04:12 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (darwin) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 15555 Cc: Eli Zaretskii , 15555@debbugs.gnu.org, Stefan Monnier , 3219@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Jerome L Quinn writes: > Eli Zaretskii wrote on 10/09/2013 12:59:26 PM: > >> From: Eli Zaretskii >> To: Stefan Monnier >> Cc: Jerome L Quinn/Watson/IBM@IBMUS, 15555@debbugs.gnu.org >> Date: 10/09/2013 12:59 PM >> Subject: Re: bug#15555: 24.3; Bidirectional display very slow with long lines >> >> > From: Stefan Monnier >> > Cc: Jerome L Quinn , 15555@debbugs.gnu.org >> > Date: Wed, 09 Oct 2013 08:26:58 -0400 >> > >> > >> And disabling bidi reordering completely eliminates the bad behavior. >> > > If you can afford that, go for it. >> > >> > IIRC this is the first report where setting bidi-display-reordering to >> > nil is really the best recommendation we can offer (and where it >> > apparently indeed helps significantly). >> >> Actually, it's not my recommendation. But the OP keeps claiming that >> nothing else works for him. >> >> My recommendation would be rather to make lines shorter. > > I can't make the lines shorter. The file I'm looking at is computer-generated. > > I can disable reordering, which does solve the speed problem for me. I'd just like > to help identify the source of the issue so that it can be resolved at some point. > >> > I consider bidi-display-reordering as a debugging tool rather than >> > a user config, so I'm not very happy about this situation. >> >> I'm not happy either (probably even less than you), but I'm not going >> to agree that slow redisplay of 14K-character lines has anything to do >> with bidirectional editing support. _Anything_ that slows down >> redisplay even a bit will have the same effect with such long lines, >> e.g., JIT font lock, Flyspell, invisible text, you name it. In fact, >> even on a reasonably fast machine (mine is a core i7 screamer) Emacs >> is unbearably slow with such long lines without reordering as well. >> Maybe the OP has an unreasonably fast machine, but that just makes his >> use case even more rare. > > I'm not sure what else I can do. I timed how long it takes to page down and > move the cursor and it's much slower with reordering enabled on my test > case. > > No, moving around with 14K lines and reordering off is not lightning fast. It > is however subsecond response on my machine. Reordering brings subsecond > response up to multiple seconds as you are further along the line. > > I am on a high-end 12 core xeon machine, so yes, the hardware is fast. FWIW, on Emacs 25 on Mac OS X, the bidi text as reported in the initial bug is still very slow. From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 26 09:40:59 2016 Received: (at 15555) by debbugs.gnu.org; 26 Jan 2016 14:40:59 +0000 Received: from localhost ([127.0.0.1]:36728 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aO4nj-000813-6G for submit@debbugs.gnu.org; Tue, 26 Jan 2016 09:40:59 -0500 Received: from eggs.gnu.org ([208.118.235.92]:57954) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aO4ng-00080q-7I for 15555@debbugs.gnu.org; Tue, 26 Jan 2016 09:40:57 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aO4nX-0004XZ-Bo for 15555@debbugs.gnu.org; Tue, 26 Jan 2016 09:40:51 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_20,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:37265) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aO4nS-0004WX-Gp; Tue, 26 Jan 2016 09:40:42 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1324 helo=HOME-C4E4A596F7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aO4nR-0006Dt-MP; Tue, 26 Jan 2016 09:40:42 -0500 Date: Tue, 26 Jan 2016 16:41:10 +0200 Message-Id: <83wpqw1jzt.fsf@gnu.org> From: Eli Zaretskii To: Andrew Hyatt In-reply-to: (message from Andrew Hyatt on Tue, 26 Jan 2016 00:13:01 -0500) Subject: Re: bug#15555: 24.3; Bidirectional display very slow with long lines References: <83wqlo461e.fsf@gnu.org> <8338obskk4.fsf@gnu.org> <83iox6qt1t.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 15555 Cc: jlquinn@us.ibm.com, 15555@debbugs.gnu.org, monnier@iro.umontreal.ca, 3219@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > From: Andrew Hyatt > Cc: Eli Zaretskii , 3219@debbugs.gnu.org, 15555@debbugs.gnu.org, Stefan Monnier > Date: Tue, 26 Jan 2016 00:13:01 -0500 > > FWIW, on Emacs 25 on Mac OS X, the bidi text as reported in the initial > bug is still very slow. Nothing was done since then to speed up redisplay for such long lines. From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 24 07:32:51 2016 Received: (at control) by debbugs.gnu.org; 24 Sep 2016 11:32:51 +0000 Received: from localhost ([127.0.0.1]:33934 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bnlCN-0002oe-G1 for submit@debbugs.gnu.org; Sat, 24 Sep 2016 07:32:51 -0400 Received: from eggs.gnu.org ([208.118.235.92]:44615) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bnlCL-0002oR-1R for control@debbugs.gnu.org; Sat, 24 Sep 2016 07:32:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bnlCC-0002kj-Nr for control@debbugs.gnu.org; Sat, 24 Sep 2016 07:32:43 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:36912) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bnlCC-0002kW-LB; Sat, 24 Sep 2016 07:32:40 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1102 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bnlC9-0000i1-Ol; Sat, 24 Sep 2016 07:32:40 -0400 Date: Sat, 24 Sep 2016 14:32:44 +0300 Message-Id: <838tuhcz37.fsf@gnu.org> From: Eli Zaretskii To: Andreas Nilsson In-reply-to: <20160924110901.5482c558@bahnhof.se> (message from Andreas Nilsson on Sat, 24 Sep 2016 11:09:01 +0200) Subject: Re: bug#24523: Base64 images makes Emacs slow References: <20160924073739.59fca4e0@bahnhof.se> <83h995dbzu.fsf@gnu.org> <20160924110901.5482c558@bahnhof.se> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -8.1 (--------) X-Debbugs-Envelope-To: control Cc: 24523@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -8.1 (--------) merge 24523 13675 thanks > Date: Sat, 24 Sep 2016 11:09:01 +0200 > From: Andreas Nilsson > Cc: 24523@debbugs.gnu.org > > 1. emacs -Q > 2. Visit https://www.base64-image.de/ and "click here" select an image > (I selected a ~200kB one) > 3. Click "show code" and copy paste the string you get into *scratch*. > 4. Now try C-v and M-v as well as type some characters, this is the > point where it lags. This creates a single physical line whose length is 280K characters. It is a known limitation of the Emacs display engine that it's very slow with such long lines. See bug #13675. From debbugs-submit-bounces@debbugs.gnu.org Wed Feb 14 14:55:32 2018 Received: (at control) by debbugs.gnu.org; 14 Feb 2018 19:55:32 +0000 Received: from localhost ([127.0.0.1]:43207 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1em39Q-00062x-5u for submit@debbugs.gnu.org; Wed, 14 Feb 2018 14:55:32 -0500 Received: from eggs.gnu.org ([208.118.235.92]:35991) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1em39O-00062k-4g for control@debbugs.gnu.org; Wed, 14 Feb 2018 14:55:30 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1em39I-0003xm-Af for control@debbugs.gnu.org; Wed, 14 Feb 2018 14:55:25 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:43655) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1em39I-0003xY-3u for control@debbugs.gnu.org; Wed, 14 Feb 2018 14:55:24 -0500 Received: from rgm by fencepost.gnu.org with local (Exim 4.82) (envelope-from ) id 1em39H-00059S-SU for control@debbugs.gnu.org; Wed, 14 Feb 2018 14:55:23 -0500 Subject: control message for bug 30457 To: X-Mailer: mail (GNU Mailutils 2.99.98) Message-Id: From: Glenn Morris Date: Wed, 14 Feb 2018 14:55:23 -0500 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) merge 15555 30457 From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 10 10:40:19 2020 Received: (at control) by debbugs.gnu.org; 10 Mar 2020 14:40:19 +0000 Received: from localhost ([127.0.0.1]:53052 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jBg3O-0007um-Ty for submit@debbugs.gnu.org; Tue, 10 Mar 2020 10:40:19 -0400 Received: from eggs.gnu.org ([209.51.188.92]:57342) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jBg3N-0007uW-CY; Tue, 10 Mar 2020 10:40:17 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:36981) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1jBg3I-0002Hs-2m; Tue, 10 Mar 2020 10:40:12 -0400 Received: from [176.228.60.248] (port=1144 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jBg3H-0006JF-DX; Tue, 10 Mar 2020 10:40:11 -0400 Date: Tue, 10 Mar 2020 16:40:12 +0200 Message-Id: <831rq0b7eb.fsf@gnu.org> From: Eli Zaretskii To: Jan Synacek In-Reply-To: (message from Jan Synacek on Tue, 10 Mar 2020 10:48:24 +0100) Subject: Re: bug#40007: 28.0.50; Emacs gets very slow when displaying a long line References: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: control Cc: 40007@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) merge 40007 13675 thanks > From: Jan Synacek > Date: Tue, 10 Mar 2020 10:48:24 +0100 > > > 1) emacs -Q > 2) M-x shell > 3) execute a program that displays a single line, about ~193000 > characters long > > I accidentaly wrote a scheme program that dumped an entire file as a > single line, about 193k characters long, into the shell buffer. Emacs' > reponse latency becomes *very* slow, especially when navigating the > point over the long line. This is bug#13675 (and others that were merged with it). We now have so-long-mode to alleviate some of the problems. From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 21 13:06:02 2020 Received: (at control) by debbugs.gnu.org; 21 Aug 2020 17:06:02 +0000 Received: from localhost ([127.0.0.1]:48187 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k9AUM-0004Jo-OQ for submit@debbugs.gnu.org; Fri, 21 Aug 2020 13:06:02 -0400 Received: from mail-yb1-f174.google.com ([209.85.219.174]:45008) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k9AUK-0004In-CS for control@debbugs.gnu.org; Fri, 21 Aug 2020 13:06:00 -0400 Received: by mail-yb1-f174.google.com with SMTP id i10so1381911ybt.11 for ; Fri, 21 Aug 2020 10:06:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:date:message-id:subject:to; bh=oO9Ukq+yL4ZHa0KQ3n/6AXU2R4rT5NZrp+6JqNA8vXs=; b=B00hZFAjjv4zhs0/bD9bxKdj1lVqPpRYMkLisYQ7tPCA2st+k4JOROGea4pw6tonnA z5DdFSEoXqRKbwiYYvb0YxRW4/DW2dF5SPeUTQccv5eE82KtrRMt+S7108n1wXbfArGB Duav4NgKnHc/o5bx8l4eMd2Lo0BnS7+TGDtt1CmKjXrbDdD0MULVpnFAcyRgqXzGHats HPmLE0/DvYYhmE0jFuFKL5paKjijmavFPvRp/Cm6ckGSbQVt0GAwRpMexsKigkkdLD5f DJxmzVtPeZP8Z2iwatMGOniG7oEqVO3P9vmVGi1B8P4mCIg3FrSoModeXXRqIw+d/4WZ cAnA== X-Gm-Message-State: AOAM530X93b2aGdrifXMvwSDK0LVHD+ncNxmkTegsH6jc6k13eBxUUgP kOOGL8BY6nftBY+omOM1HUfDWOrVKoUpzF64ysd9AxvEhwvvsA== X-Google-Smtp-Source: ABdhPJyDk5CYbpOPdrj7bSkIgXmyc2pJB2JjTXo25T+CIu9inVCfq78tsVKYcz61E2t2lbTEqiuM16cFPYs0F6tif1U= X-Received: by 2002:a25:b290:: with SMTP id k16mr4822633ybj.389.1598029554876; Fri, 21 Aug 2020 10:05:54 -0700 (PDT) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Fri, 21 Aug 2020 10:05:54 -0700 From: Stefan Kangas MIME-Version: 1.0 Date: Fri, 21 Aug 2020 10:05:54 -0700 Message-ID: Subject: To: control@debbugs.gnu.org Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 2.5 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: merge 13675 32523 thanks Content analysis details: (2.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (stefankangas[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.219.174 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.219.174 listed in wl.mailspike.net] 0.2 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different 2.0 BLANK_SUBJECT Subject is present but empty 0.0 UNPARSEABLE_RELAY Informational: message has unparseable relay lines X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: merge 13675 32523 thanks Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.219.174 listed in wl.mailspike.net] -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.219.174 listed in list.dnswl.org] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (stefankangas[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.2 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different 2.0 BLANK_SUBJECT Subject is present but empty -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager 0.0 UNPARSEABLE_RELAY Informational: message has unparseable relay lines merge 13675 32523 thanks From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 21 13:42:23 2020 Received: (at control) by debbugs.gnu.org; 21 Aug 2020 17:42:23 +0000 Received: from localhost ([127.0.0.1]:48238 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k9B3X-0007VV-2l for submit@debbugs.gnu.org; Fri, 21 Aug 2020 13:42:23 -0400 Received: from mail-yb1-f178.google.com ([209.85.219.178]:35257) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k9B3S-0007V9-Lg for control@debbugs.gnu.org; Fri, 21 Aug 2020 13:42:21 -0400 Received: by mail-yb1-f178.google.com with SMTP id y134so1460055yby.2 for ; Fri, 21 Aug 2020 10:42:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:date:message-id:subject:to; bh=EWV69o2tJibW/qvbUF6dqOcHAYWps8Mkc9e4bv8rbhU=; b=YEkv0iJYDZN6/jvtVYM+J+9Buy6yaMMVfwpDA2uVayEEXsKmG5G2AHclYojzVAdWyi c5bLtHXM//llNE9Gd90wXhfJ4cXrQISpaEP5Dmp9CfXUwPPVm99Dbvylxb5I3IauF6NW d+06q/oRRvxfyKJvOkxjkDTU+KahbmbGGLTLXgGw+T1RL+8W68u16qai50C05UfwJ47o gGFkTUM7S3p/xeT3Tv+90nf7zzqMp8lNJphMaQJ59fDMikCxVelwwKKKbTbiFqvtkd+Y g28ksVg4znTVM7Sm5bvk2HFjxOMusIfjRqalwGwy8R7Bh8UH1gt8Hzc4e8JSRSFUPNSf tH+Q== X-Gm-Message-State: AOAM532EKDD4THkT5g2xf++7vJ3rgfsWJRYCXq0rjqH7KsH/VZ4bKwLS S3mOHKcIar3cyUJfwGx7PZkobleXeCaY2Se+WxhOv4h/gnWEgQ== X-Google-Smtp-Source: ABdhPJyhkJ+ZWtZcBFaHE1oBMiKOVWOQnTSGkJIWAH4N+fWv8b8N8GlbjMdcPi5Fg7F2qQj4/LPz1s7H71KL6bxtXLc= X-Received: by 2002:a5b:410:: with SMTP id m16mr4981727ybp.309.1598031732879; Fri, 21 Aug 2020 10:42:12 -0700 (PDT) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Fri, 21 Aug 2020 10:42:11 -0700 From: Stefan Kangas MIME-Version: 1.0 Date: Fri, 21 Aug 2020 10:42:11 -0700 Message-ID: Subject: To: control@debbugs.gnu.org Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 2.5 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: severity 22143 normal merge 13675 22143 thanks Content analysis details: (2.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (stefankangas[at]gmail.com) -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.219.178 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.219.178 listed in wl.mailspike.net] 0.2 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different 2.0 BLANK_SUBJECT Subject is present but empty 0.0 UNPARSEABLE_RELAY Informational: message has unparseable relay lines X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: severity 22143 normal merge 13675 22143 thanks Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.219.178 listed in wl.mailspike.net] -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.219.178 listed in list.dnswl.org] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (stefankangas[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.2 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different 2.0 BLANK_SUBJECT Subject is present but empty -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager 0.0 UNPARSEABLE_RELAY Informational: message has unparseable relay lines severity 22143 normal merge 13675 22143 thanks From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 23 04:59:21 2022 Received: (at control) by debbugs.gnu.org; 23 Jul 2022 08:59:21 +0000 Received: from localhost ([127.0.0.1]:43440 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oFAym-0002AM-Vv for submit@debbugs.gnu.org; Sat, 23 Jul 2022 04:59:21 -0400 Received: from quimby.gnus.org ([95.216.78.240]:49244) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oFAyl-0002A7-My for control@debbugs.gnu.org; Sat, 23 Jul 2022 04:59:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Subject:From:To:Message-Id:Date:Sender:Reply-To:Cc: MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=ZOx7Or2+rJP/3U1mbA613hdzQoIuBCaxaSR0wzztDYo=; b=TvSFuQGmBnIZFLC5hrnyBpbKew KxSTZ4bKgdNagP4ifRZ5WDMNpXTRFbQHB/xYij+kk6DbSJq/H92szpaQDDrixujkYMvHvfbz00rBM +fumZNM2Z+l1I0Madiv/J93c94FN5KfQ3WuoVCqFBIUk/8Q2iQoYKtbXkL6iVo2xBW2w=; Received: from [84.212.220.105] (helo=joga) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oFAyd-0000g5-U0 for control@debbugs.gnu.org; Sat, 23 Jul 2022 10:59:13 +0200 Date: Sat, 23 Jul 2022 10:59:08 +0200 Message-Id: <87mtd0tdb7.fsf@gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #40007 X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: close 40007 29.1 quit Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) close 40007 29.1 quit From unknown Sun Jun 22 07:55:18 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sat, 20 Aug 2022 11:24:05 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator