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: Mon, 24 May 2021 11:48:16 +0300 Message-ID: <80A25FCA-2CF4-433F-B82F-4B37ED5BC6DC@gnu.org> References: <831r9xjrho.fsf@gnu.org> <5754E85B-9840-416B-B9C1-E6B2B1FC0114@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="5082"; 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 Mon May 24 10:49:22 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 1ll6H3-000190-AT for ged-emacs-devel@m.gmane-mx.org; Mon, 24 May 2021 10:49:21 +0200 Original-Received: from localhost ([::1]:33362 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ll6H2-0005sm-Cf for ged-emacs-devel@m.gmane-mx.org; Mon, 24 May 2021 04:49:20 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52778) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ll6G4-0003qm-5m for emacs-devel@gnu.org; Mon, 24 May 2021 04:48:20 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:60046) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ll6G3-00076I-Hk; Mon, 24 May 2021 04:48:19 -0400 Original-Received: from [2a02:14f:1fb:57ce::1f5a:dfeb] (port=40160) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ll6G3-0006gs-7o; Mon, 24 May 2021 04:48:19 -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:269740 Archived-At: On May 24, 2021 11:07:42 AM GMT+03:00, Aaron Jensen wrote: > On Mon, May 24, 2021 at 12:37 AM Eli Zaretskii wrote: > > > > Why does it look suspect to you? Don't you also see the same code > called to process the other faces in the buffer? >=20 > What looks suspect is that the exact same call is made so many times > for the exact same faces and that call gets slower proportional to the > number of faces you have because of the linear search=2E Fewer faces =3D= =3D > less work, and when something is called so many times it may be worth > further optimization or caching=2E But we do the same for every face in the buffer, not just for the line-num= ber face=2E When you turn on the line-numbers display, a single face gets = added to the faces used by buffer text -- the font-lock faces each major mo= de uses=2E So how come adding just one face to the dozen of others has suc= h effect? You are right that there are better ways than linear search to look up a f= ace's attributes by its symbol, and there is a patch in the works to do jus= t that=2E But the puzzle here is elsewhere=2E Especially since you report= significant slowdown due to line numbers in "emacs -Q" as well=2E > > An Emacs face that is identified by name needs to be converted to > the collection of the face's attributes, so that Emacs could merge > faces and display them=2E This is what lface_from_face_name does=2E An= d > it does that for any face specified in the buffer by its symbol=2E So > how come addition of just one face and a few characters which have > that face have such a profound effect in your case? >=20 > I'm not sure I track your last question=2E In my case it's the addition > of 400-600 faces, none of which are used in the buffer=2E They just > exist in the alist that lface_from_face_name_no_resolve scans with > assq_no_quit=2E But the same face alist is searched for faces that _are_ in the buffer: al= l the font-lock faces=2E The line-number face adds just one face to those = which Emacs must look up in that alist=2E IOW, what puzzles me is not the difference between "emacs -Q" and your cus= tomizations, what puzzles me is the difference betwen with and without the = line numbers, in the same basic configuration=2E It cannot be explained by= the length of the frame's face alist alone because in both cases that leng= th is almost identical: you add one face to the list of hundreds=2E This is why TAGGEDP via CONSP is a hotspot in my code, > because it's called 600 * 700k (or some multiple thereof) times or so=2E > assq_no_quit via merge_faces accounts for 1=2E43s of 6=2E94s in one of m= y > profiles=2E How many times is it called with line numbers turned off, and what is the = increase in the number of calls due to line numbers in percents? Does it c= ome anywhere near the slowdown shown in your benchmarks?