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: Wed, 15 Mar 2017 16:46:33 -0400 Message-ID: References: <559F9FAF.8090708@live.com> <83lgvd581m.fsf@gnu.org> <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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="vIeqGaFmquK0wG2Iuv8F4RF1TIWFElRAG" X-Trace: blaine.gmane.org 1489610868 13591 195.159.176.226 (15 Mar 2017 20:47:48 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 15 Mar 2017 20:47:48 +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 Wed Mar 15 21:47:43 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 1coFpf-0002st-J5 for geb-bug-gnu-emacs@m.gmane.org; Wed, 15 Mar 2017 21:47:43 +0100 Original-Received: from localhost ([::1]:39469 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1coFpl-0004dr-Bn for geb-bug-gnu-emacs@m.gmane.org; Wed, 15 Mar 2017 16:47:49 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41961) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1coFp1-00042y-Kj for bug-gnu-emacs@gnu.org; Wed, 15 Mar 2017 16:47:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1coFp0-0004x3-32 for bug-gnu-emacs@gnu.org; Wed, 15 Mar 2017 16:47:03 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:59363) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1coFoz-0004wk-Vk for bug-gnu-emacs@gnu.org; Wed, 15 Mar 2017 16:47:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1coFoz-00084o-Ok for bug-gnu-emacs@gnu.org; Wed, 15 Mar 2017 16:47: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: Wed, 15 Mar 2017 20:47: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.148961081531034 (code B ref 21028); Wed, 15 Mar 2017 20:47:01 +0000 Original-Received: (at 21028) by debbugs.gnu.org; 15 Mar 2017 20:46:55 +0000 Original-Received: from localhost ([127.0.0.1]:57562 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1coFos-00084S-5V for submit@debbugs.gnu.org; Wed, 15 Mar 2017 16:46:54 -0400 Original-Received: from mout.kundenserver.de ([212.227.126.133]:61981) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1coFop-00084C-EK for 21028@debbugs.gnu.org; Wed, 15 Mar 2017 16:46:52 -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 0MZhl4-1cWAjl2idy-00LYDf; Wed, 15 Mar 2017 21:46:43 +0100 In-Reply-To: <831styblhv.fsf@gnu.org> X-Provags-ID: V03:K0:GbtjTRSTA3kBLxM5NX9RQQlTYfeA26SEzfQBgYpR/6calHdD0+X 0cBrCVGHZe591K7ZartwR5tbkB9nShyr9jqbNP2WphjlOSUQaJSSCjC8Y9tkN6IWUBX9m48 8+2Nsaa+wRFvZdrVXPC8lKlytxhX44kbo/Xpc2r24uLZJco2usXm19TcKKSR7aASOX7XKiY uGM7kRGb4DzfSNYQpvesg== X-UI-Out-Filterresults: notjunk:1;V01:K0:yHHsPt5zkb4=:1bveH7f3ZSgx/MHs6TXXuf F+Dg5CbrDLI8U3x6EDWe5KY0rBbhHk1SjYUdkLJBI0Nu54hz8KJ0FAlUUd4oGIx+5b14nuebF nzeep0mE0cOlzM+sV43atBciNud9ylnZcEUCQKhuhKv1oQg3yXHwiHSOoOkG1Ba5rkAlxZE6/ jqUl48/JADCXJRB7J+SjZAPVN+xlpA5MH8I1yQIhlM247cngJs0ECDDsDY+HdcyZwq4FhYZwz 0luMNqWMv6efxVSz9xIKU4zUSHI32XDTRw2hXpR+Yg/vm/Z4kBnJxiecg1IIj4irFORy1e0ha 7e1w4PsOYOL2+9PU6Agp6bddoIoUGu6CBXemtsxBoyFmSctQoQlckWjiBJWD1nEGtYf1eshXs 4o9JqUWpvpAvWhaTpZz4Y12cy5Bx9S7SSQImTzYLeYVoz3UodeuShyRKSPnshbjwqWeZQ8lNs FOwqp587irzd+AHgsFn/QFXFn64StxhbD/YcSynlBXX1CkR5x6ZBPhkm2eJa45dgDSzyOwxZr AEdPL9qi8kW2PrniaRUyPtkHcO6rcP07Gybw0Q3xebH6p3O2RQJZ6+EFlSyQdZWqqtF71kqci MwiQSX9HxneP1mcU7Soc4Aj9suDcpkwTh4U07hxPqLu1kdTq3lbHqfcQumbzlOKMxxrVitZWW D0qQE1zYRy+B2uk3X8eF6jYxuZDArb73IRMQyWd0gfUpz173YNVznbPUPzeEYilTrq9Q= 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:130625 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --vIeqGaFmquK0wG2Iuv8F4RF1TIWFElRAG Content-Type: multipart/mixed; boundary="oXiVkbFfmDoLQuavG2kNXGEqGM8974UA1"; protected-headers="v1" From: =?UTF-8?Q?Cl=c3=a9ment_Pit--Claudel?= To: Eli Zaretskii Cc: 21028@debbugs.gnu.org Message-ID: Subject: Re: bug#21028: Performance regression in revision af1a69f4d17a482c359d98c00ef86fac835b5fac (Apr 2014). References: <559F9FAF.8090708@live.com> <83oa095eaw.fsf@gnu.org> <83lgvd581m.fsf@gnu.org> <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> In-Reply-To: <831styblhv.fsf@gnu.org> --oXiVkbFfmDoLQuavG2kNXGEqGM8974UA1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2017-03-15 11:36, Eli Zaretskii wrote: > The problem here is that opening a font and looking up a character is > very expensive, certainly when there are hundreds of fonts installed. > So Emacs filters the fonts according to the scripts they claim to > support, and only opens those which appear to be valid candidates for > the script of the character it needs to display. By using 'unicode as > the script when you set up your fontset, you actually trip Emacs by > telling it to try this font for every character it needs to display. > You should instead specify the scripts which the fonts supports well. Ok =E2=80=94 but why wasn't it slow in 24.3? And why does the number of = fonts matter, if I'm only adding one (Symbola) with 'unicode? > 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. > So using more accurate scripts gives a major improvement. Good. It also seems to negate the previous conclusion, right? In these fast exa= mple I'm still adding Symbola with 'unicode =E2=80=94 but adding Ubuntu M= ono with 'latin. Shouldn't that be slow, according to your explanation a= t the top of this post? >> For me specifying the registry doesn't seem to do anything >=20 > 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 have no clue what it means. >>> (set-fontset-font fontset 'unicode base-spec nil) >>> >>> This should only specify 'latin, 'greek, and 'cyrillic (one such >>> line for each of them), as 'unicode is a blatant lie. >> >> But I want more than 'latin, 'greek, and 'cyrillic: I want "any charac= ter that=20 >> this font supports". Ok, noted for Emacs >=3D 25. > You can use a font utility, such as Fontforge, to see which blocks the > font supports, and how many characters from each block it can display. > My conclusion from looking at Ubuntu Mono is that the above 3 scripts > are the only ones it supports well; the rest are not covered well at > all. You can, of course, add more scripts if you need them, but the > downside will be that some of those scripts will be displayed by a mix > of more than one font, which I think will make the display ugly. I don't care about the display being pretty as much as it being properly = align (vertically), which means that using Ubuntu Mono helps a lot. > 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 chara= cters, so why would this matter? >>> Can you ask some of those people to show their fontset setup? I'd=20 >>> like to know how different they are from your setup. >> >> They essentially use this: >=20 >> (dolist (ft (fontset-list)) >> (set-fontset-font ft 'unicode (font-spec :name "YOUR-USUAL-FONT")) >> (set-fontset-font ft 'unicode (font-spec :name "Symbola") nil 'appen= d)) >=20 > Well, maybe with the new insights you have now, you can recommend them > better setups which don't use 'unicode'. I think I still have a blurry picture of the whole process, or at least i= t sounds very complicated. Is it really the following? * Pick a good monospace font. Set that as the default Emacs font (this i= s easy) * Pick a good math font. Symbola is easier than others, because Emacs kn= ows about it. * 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 * Create a set-fontset-font rule for each range and character. Figure ou= t the font's registry too. Add all these rules with 'append, though for = better performance you can use 'prepend, but for that you'll need to know= which ranges the first font supports, too. This sounds too complicated, given that the simpler approach used to work= in Emacs < 24.4. In CSS, the rule would be 'font-family: "Ubuntu Mono",= "XITS Math"'. In Emacs < 24.4, the following worked =E2=80=94 and it wo= rks in Emacs 25 with your patch: (dolist (ft (fontset-list)) (set-fontset-font ft 'unicode (font-spec :name "Ubuntu Mono")) (set-fontset-font ft 'unicode (font-spec :name "Symbola") nil 'append)= ) In Emacs 25, given that symbols use the default font, it looks like the = following should work, at least with your patch: 25.1/src/emacs -Q --eval "(set-fontset-font \"fontset-default\" 'unicod= e (font-spec :name \"XITS Math\") nil 'prepend)" It seems to work ok =E2=80=94 but without your patch, it's unbearably slo= w too. This is better, performance-wise: 25.1/src/emacs -Q --eval "(set-fontset-font \"fontset-default\" 'unicod= e (font-spec :name \"XITS Math\") nil nil)" but it causes Emacs to use different fonts in different buffers (the conc= rete example is that when I press C-x 8 RET, type alpha, press TAB, and c= opy the contents of the completion buffer to *scratch*, the symbols don't= appear in the same font in both buffers. Cheers, Cl=C3=A9ment. --oXiVkbFfmDoLQuavG2kNXGEqGM8974UA1-- --vIeqGaFmquK0wG2Iuv8F4RF1TIWFElRAG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJYyagpAAoJEPqg+cTm90wjn+EQAJr4UOUT+lfn3TiG93Nuf49o kzsq96eVm9RPn3JALKD3OnSHrPqifeRn5wSh4/WFOJ/dGOFDya1ooOz1OVT1QQcI 8+IwYPhXwUKrb19emYxUk2tDuyrcGfMZFUYidJ8QEhch8SDNfMq0xkPzFnOPT1/d kcW81nGgIOy/KaLtWNh6/yJQcTjaz32AGRxy7E2+1jI2DPMjeIRHvaQie66+LZdx pE8EsydNlYeCiAfn7DbO/Z5hkTCGxNsnRtB0p5RQkmgxjokL/ylhs2gPL++xFNit 7X7PgCSAJcWEoYv4yqbIzegUpiOX2jrlbafgefqz3HaIF5WCNwLcJDp1ODAoVUUF hOaKqrKtThVtvNcDdFu5m03byGk4QrmrqqVtqUKuFSBVdlhwJeCGbgmj4vGYF8+N B1AlexfHrpVskgTB1AhX1wHQOTYCVvtxNutWKmpDMpP/CAGpp+KYeaM+75oXjNhz 3L8WHg+U/9I96L6Fxju8i9oegxFPrwJ+YUrVZ2AIVkST2/QUjVQGW9fGTNtjT4tG fwR9OBSYqNRcCK6q2z/3hXFPKbhV/met10fDVfCL+wxtDYNHln6FGvxzeyZ9YsTo 4sgX78WuW6I0z/7BhsWwLZKj5R28jOYvvnkBDy24IZx3BhEhhXqGe9rIQerZ+61c 1qPPKXQcQd3YRCltqw6Y =6wiU -----END PGP SIGNATURE----- --vIeqGaFmquK0wG2Iuv8F4RF1TIWFElRAG--