From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: macOS metal rendering engine in mac port Date: Tue, 25 May 2021 08:41:45 +0300 Message-ID: <279F3242-E556-42C9-8489-4DD8F538938E@gnu.org> References: <5754E85B-9840-416B-B9C1-E6B2B1FC0114@gnu.org> <80A25FCA-2CF4-433F-B82F-4B37ED5BC6DC@gnu.org> <831r9wdrjr.fsf@gnu.org> <83v978ccbc.fsf@gnu.org> <83sg2cc8m7.fsf@gnu.org> <83pmxgc681.fsf@gnu.org> <83mtskc4zl.fsf@gnu.org> <83lf84c4p7.fsf@gnu.org> <83k0nncznr.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31137"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: K-9 Mail for Android Cc: Alan Third , YAMAMOTO Mitsuharu To: emacs-devel@gnu.org,Aaron Jensen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue May 25 07:42:53 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1llPq9-0007yw-A5 for ged-emacs-devel@m.gmane-mx.org; Tue, 25 May 2021 07:42:53 +0200 Original-Received: from localhost ([::1]:53376 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1llPq8-00077u-DR for ged-emacs-devel@m.gmane-mx.org; Tue, 25 May 2021 01:42:52 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48598) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1llPpB-0006QQ-5J for emacs-devel@gnu.org; Tue, 25 May 2021 01:41:53 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:36096) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1llPp9-0003Dc-BA; Tue, 25 May 2021 01:41:51 -0400 Original-Received: from [2a02:14f:81:af0d::1] (port=50046) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1llPp7-0002FZ-GP; Tue, 25 May 2021 01:41:51 -0400 In-Reply-To: Autocrypt: addr=eliz@gnu.org; keydata= mQENBF+pf4UBCAC6vjkWLSAsQpe8YIGKLQzNOJx/IjGtCdFF8uzmO5jmME+SD8ROuJN+t5KXVw58 uzu75EFD0vHTY9e+udJ2gkpuy0NnzkFcbumdLLo2ERKCoSctZZRhzKXI5z5cHxCqW0B2ygHRrRLt oNlGID7bAgcgSViT1ptGqTXO7zGVu4Airok7dNzcPtHgns8GlR5YAFX0TvE6oGd0l2VPghNeVJKJ OjrbfhoDxl3ucFpqbqMH8z9HTLDOFpz8UaYYUdJMi3xX6vwTZxI2sM2RRVLUpZyllAkSMI4lln1O OgazM/62DJUs/rKIHKBnF6h3/qsJUjUYXaAHbrXY26mWllAd536lABEBAAG0I0VsaSBaYXJldHNr aWkgKGVsaXopIDxlbGl6QGdudS5vcmc+iQE4BBMBAgAiBQJfqX+FAhsDBgsJCAcDAgYVCAIJCgsE FgIDAQIeAQIXgAAKCRCRwSYvAeuNOYUQB/4/iIKKOG45ijNaRoTvmJJZMvj1S07WQxEm7c5SHEeE QbLOAxB9vESOV7sLueuN3oqEndtzyYt4x1WTSBmHFF7h5fcCMjBs41siOIp5Sj/xD0Bvaa0IKGCR SZ7PAo8Mq3wgajXpTpn9vxE2PmtzA8KdEE0K1+f9pVAfOpUIcCl44rIxLUW352XG0y7iz6c/O6LB 1deOKMiKFctKO7pBti1dJEm1ImewLH3H8uTbwspLOs3EB8xhsESxmTidnze68HX2jt+2EeMgCdki NU+LWbexQZPfIS7+ZmE06ll0v6+Jy7ZdTkCCRypKWTnW7pIFsq/p4kybV8O/kHSV6B4vvQBfuQEN BF X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:269835 Archived-At: On May 25, 2021 7:42:45 AM GMT+03:00, Aaron Jensen wrote: > On Mon, May 24, 2021 at 7:31 PM Eli Zaretskii wrote: > > > > No mystery: face merging is just a small fraction of what redisplay > > does, so the twofold increase in face merging shouldn't slow down > > redisplay too much=2E >=20 > Apple removed the text export feature of Instruments=2E Sigh=2E I've > attached screenshots of a much more expanded profile=2E It's not just > the merge_faces, it's slower in multiple places=2E >=20 > 2060ms slower in total (40% slower): > 444ms in maybe_produce_line_number, only 227ms of which is merge_faces > 576ms more in drawing glyphs (78% slower) > 490ms more copying surface contents (18% slower) What are you comparing? When line numbers are off, maybe_produce_line_num= ber shouldn't be called at all, and so shouldn't the merge_faces calls it m= akes=2E > With emacs -Q, the merge_faces tax isn't very high=2E It's just 10% of > the slowdown I saw in this benchmark=2E It's just that that tax scales > with the more faces I have, so it becomes a bigger chunk=2E That's a general problem with faces, which will hopefully be fixed soon=2E= Nothing to do specifically with line-number display=2E > Alan, I could understand why drawing glyphs would take longer (there's > more to draw when there are line numbers), ??? Because line numbers add ~3 glyphs to each line? How can this explain= any significant slowdown? Do you see something similar if you add 3 chara= cters to every line and benchmark the scroll?