From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: =?UTF-8?Q?Cl=C3=A9ment?= Pit--Claudel Newsgroups: gmane.emacs.bugs Subject: bug#21028: Performance regression in revision af1a69f4d17a482c359d98c00ef86fac835b5fac (Apr 2014). Date: Thu, 16 Mar 2017 17:23:13 -0400 Message-ID: <2b7b1b16-4be4-a3cc-7e92-3f16379ab2aa@live.com> References: <559F9FAF.8090708@live.com> <83a8br6hq0.fsf@gnu.org> <672a0c69-4352-735f-cba4-025e642626ea@gmail.com> <83vauf50wb.fsf@gnu.org> <7408d59c-92ba-b879-5ac1-3cd5eee9b4db@gmail.com> <83tw9z4zzp.fsf@gnu.org> <2cad0da9-c931-b547-07bb-efec2f2bcf1f@gmail.com> <83h95w0w3p.fsf@gnu.org> <27853273-e6d8-077e-b9e0-b2bec2fe1fae@gmail.com> <834m1v2630.fsf@gnu.org> <1c224dc1-bd71-a910-b7cf-00313e4aec40@live.com> <83efy2cx5n.fsf@gnu.org> <3c3e8384-3412-f5a5-3ab2-a7eb4e699f1c@live.com> <83d1dmcrnl.fsf@gnu.org> <39fe847e-ef8a-149f-4478-d02e7c794c9a@live.com> <837f3tch7y.fsf@gnu.org> <1e7bc066-3f29-3897-5039-de7233efc58a@live.com> <83y3w9ay6y.fsf@gnu.org> <16f9db27-dd0f-ddaf-2f34-45b9fd4e69c6@live.com> <83k27rc15x.fsf@gnu.org> <79f4e3ce-6284-8fc5-fd8f-9f0c9cebe873@live.com> <831styblhv.fsf@gnu.org> <83ziglz1gy.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1489699602 17225 195.159.176.226 (16 Mar 2017 21:26:42 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 16 Mar 2017 21:26:42 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 Cc: 21028@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Mar 16 22:26:37 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cocui-00035g-T1 for geb-bug-gnu-emacs@m.gmane.org; Thu, 16 Mar 2017 22:26:29 +0100 Original-Received: from localhost ([::1]:45857 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cocun-0007Nm-BC for geb-bug-gnu-emacs@m.gmane.org; Thu, 16 Mar 2017 17:26:33 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40979) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cocsQ-0005G2-Aq for bug-gnu-emacs@gnu.org; Thu, 16 Mar 2017 17:24:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cocsM-0002bX-CD for bug-gnu-emacs@gnu.org; Thu, 16 Mar 2017 17:24:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:32921) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cocsM-0002bP-8p for bug-gnu-emacs@gnu.org; Thu, 16 Mar 2017 17:24:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1cocsL-0004Mn-V8 for bug-gnu-emacs@gnu.org; Thu, 16 Mar 2017 17:24:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: =?UTF-8?Q?Cl=C3=A9ment?= Pit--Claudel Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 16 Mar 2017 21:24:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21028 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 21028-submit@debbugs.gnu.org id=B21028.148969940416736 (code B ref 21028); Thu, 16 Mar 2017 21:24:01 +0000 Original-Received: (at 21028) by debbugs.gnu.org; 16 Mar 2017 21:23:24 +0000 Original-Received: from localhost ([127.0.0.1]:59353 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cocrk-0004Lr-4Z for submit@debbugs.gnu.org; Thu, 16 Mar 2017 17:23:24 -0400 Original-Received: from mout.kundenserver.de ([212.227.126.133]:50902) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cocrh-0004Ld-UM for 21028@debbugs.gnu.org; Thu, 16 Mar 2017 17:23:23 -0400 Original-Received: from [18.26.2.123] ([18.26.2.123]) by mrelayeu.kundenserver.de (mreue003 [212.227.15.168]) with ESMTPSA (Nemesis) id 0Lno8B-1cI4PF3yW7-00huei; Thu, 16 Mar 2017 22:23:15 +0100 In-Reply-To: <83ziglz1gy.fsf@gnu.org> X-Provags-ID: V03:K0:MsmbVo4/tdIGEgefLdC7HbD1syaHrtX4TXfcEyfZmXJuOlvVNgD AS+aIqUEuJJAdIsMSM79O3+vNZxoa4Pgo8E8hOnxh1inWbrUh8xcFPYPiqATOQmHIzpiFE7 cP9EXOHjANIbP3Vk69GOS0UHisjMokpEaMY84fhjNf5Edfd9Cy727WRFwc6iPv9TE3G5yum WMxEoG5LwvlAb4CZUwzRA== X-UI-Out-Filterresults: notjunk:1;V01:K0:o2JkAp/u8Kk=:zRoEv88lKG46RQfiK6Z2Jv s1ncVq9gFy19SX9GiIt8kVpYTwtB/CIlly4+vkW37GSbgUaNttF+mg5wyCsW+HpxyNQyMYDEE sgQB4aXCtY0O4qzW/h6tEQTiyjrV98T5q05GuzEMk9vHoczYaCb0by0badnzBXT1a9peFsDBK Ead+QUtrHF1JsJDy1yvQKNRiPKXVaIVf67aA5qXW1RylwbtDb0D95AmvV4BWjWwh1SUkIfwcQ I7J+waX5JT9GN8iaqKI/BpHGEIh4DsP7n6EkZb13nj886LqizgTNkKzfHd/q4nErSbqGKKQbW A1MdfYvCg17UM6kYfkBC7yLEKq1BorOVPcQAzhWMveYZDO/fg2BGJvyiAM/WY3nLmLYnsDxyB o7Et/sDKyuIgBWsHNRM0fgqPDsmZqUSi4Q1yHTN+K0MfFOhYl1do83/hjckUeiYKKL19qtZ8i e0Y5dJyIrDi4KvT1/GHtd8lbivUjZqLGLxaDfSvnopg/BYd0evzt3zIsKG4Z1zE0O7s7XgKGO PXqRmmRniAfRV6Lpsczcys05hIkl7jezQkqyR/eg4cpy1CJ2QjaVBXtnqQd5uZMwT0CeL0sgz 0AfDiFR3YR2d7mjeYutTG1vWbm8AIZNV4tUQ4AY+Pdy/AyWFVPm/Ul3dr+l5pmmBjWOsq0S4w LCgAd+aiIZek8MOi8FGEnNoLuO3jVhoj3XAi+xjfId1St+08pc2rPV5g1zQVSJygJLYGFyjam NVHRu4h3XQjNpnbG X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:130653 Archived-At: On 2017-03-16 11:27, Eli Zaretskii wrote: >>> You should instead specify the scripts which the fonts supports well. >> >> Ok — but why wasn't it slow in 24.3? > > That's the question about the significance of the zero_vector in the > font-cache, the patch you want to apply. I'm still struggling with > understanding why it speeds up the font search. Got it, thanks. I don't know whether that'll be useful, but I uploaded a pre-built virtual machine to https://people.csail.mit.edu/cpitcla/emacs-bug-21028.ova ; maybe this is a viable option (it should be much easier to download a VM than to rebuild one, I hope). It was produced using the instructions that I posted earlier. On that machine, here are the times I get for the benchmark you posted earlier: emacs@emacs-VirtualBox ~ $ time emacs/emacs-25.1/src/emacs -Q --eval "(progn (set-fontset-font \"fontset-startup\" 'unicode \"Ubuntu Mono\" nil) (set-fontset-font \"fontset-startup\" 'unicode \"Symbola\" nil 'append) (dotimes (_ 5000) (insert (make-string 20 8658) \"\n\")) (goto-char (point-min)) (sit-for 0) (condition-case nil (while t (scroll-up) (sit-for 0)) (error nil)) (run-with-idle-timer 0 nil #'kill-emacs))" real 5m54.574s user 0m54.612s sys 1m17.496s I loaded this VM on a different machine and confirmed that I could reproduce the problem in the guest (2s without fontset declarations, and >4m with fontset declarations). I wasn't able to reproduce the bug on the host, though, mirroring your unsuccessful reproduction attempts. I wonder if something's wrong in Linux Mint… that host wasn't running Mint. Maybe this pre-built VM can help reproduce, and thus understand, the underlying problem? Otherwise, maybe you could recommend a resource that I should look into to debug the problem myself locally? >> And why does the number of fonts matter, >> if I'm only adding one (Symbola) with 'unicode? > > Any font has several variants, and they are all checked. Moreover, > checking too many fonts conses a lot of Lisp data, which is likely to > trigger GC, which is likely to throw away font caches, which will then > require us to check those fonts again. Thanks, understood. >>> That shouldn't be a problem in Emacs 25: it by default uses the >>> default face's font for any punctuation and symbol characters for >>> which the font has glyphs, even if the fontset specifies a different >>> font for punctuation and symbol blocks. >> >> Neat. Though of course that doesn't help for Emacs < 24. > > Users who care about fonts and exotic characters shouldn't stay with > Emacs 24. Understood as well. >> In these fast example I'm still adding Symbola with 'unicode — but >> adding Ubuntu Mono with 'latin. > > Ubuntu Mono _is_ the problem. Symbola has very good coverage of > almost all Unicode blocks, so it is not the problem. Ok, I think I understand better now. But I'm still confused: why would the following be slow, then? 25.1/src/emacs -Q --eval "(set-fontset-font \"fontset-default\" 'unicode (font-spec :name \"Symbola\") nil 'prepend)" To clarify: it isn't slow with the example of plenty of ⇒ characters, but it's still slow if I use a more diverse set of symbols or letters, like e.g. ⍺⍶ᷧΑΆἉἍᾍἏᾏᾉἋᾋᾹΆᾼἈἌᾌἎᾎᾈἊᾊΆᾺᾸαάἁἅᾅἇᾇἃᾃᾁᾱάᾴᾶᾷἀἄᾄἆᾆἂᾂᾀάὰᾲᾰᾳⱭⱰɑᶐꬰꭤɒ𝚨𝜜𝜶𝛂𝛢𝛼𝝖𝞐𝞪𝝰ᵅᶛ So although I think we're converging to a fix for my font config and the use case where Symbola covers everything, there's still an underlying problem that would be great to fix (and your patch does fix it). >>> That could sometimes be the case, but I have found that in some cases >>> omitting the registry for characters beyond Latin-1 can be a major >>> setback. So I recommend to always use it. >> >> Ok. Could Emacs not infer it? > > I think Emacs still goes by the XLFD rules, which require iso8859-1 be > the default. I don't know how important it is to keep that > compatibility. Thanks. >>> Moreover, Emacs cannot compose glyphs that come from different fonts, >>> so you will sometimes see decomposed display if you request a font for >>> scripts where its support is incomplete. I think this is an important >>> factor for users of prettify-symbols-mode in particular. >> >> Why? prettify-symbols-mode composes strings (typically) into single characters, >> so why would this matter? > > I imagine that prettify-symbols-mode is not limited to single existing > characters, but if it is, this issue is indeed not relevant to that > mode. The basic interface that it provides is indeed limited to that, so you can trick it by adding arbitrary composition strings to prettify-symbols-alist. >> * Download and install fontforge. Figure out which ranges the math font >> support, and all the characters that it supports that are not punctuation or >> symbols, too > > Not needed, as long as the default font is set up via > default-frame-alist. Ah, I see. > What happens if you don't do this? Which font is used for math > symbols? Or are the problems with symbols other than math symbols? > IOW, I don't understand fully why you need to set up XITS Math in the > fontset, what is missing/incorrect/ugly if you don't? I think this is due to my not explaining it properly, or trying to hard to make minimal examples. In can answer separately for myself and for the other user configurations I've looked at. For myself, it's a matter of monospace fonts: that is, I want all characters to occupy the same width, so I don't use Symbola: instead, I use a version of XITS Math edited with FontForge to have equal widths for all characters. I also prefer as many characters to be displayed by the same font. For other users, we had cases were Emacs displayed an empty rectangle until we added an explicit set-fontset-font with Symbola. Cheers, Clément.