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: Sat, 29 May 2021 19:49:21 +0300 Message-ID: <83bl8t5vu6.fsf@gnu.org> References: <83k0ni6pje.fsf@gnu.org> <83eedq6mvm.fsf@gnu.org> <83zgwd6gk3.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30467"; mail-complaints-to="usenet@ciao.gmane.io" Cc: alan@idiocy.org, emacs-devel@gnu.org To: Aaron Jensen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat May 29 18:50:05 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 1ln2A1-0007jJ-HG for ged-emacs-devel@m.gmane-mx.org; Sat, 29 May 2021 18:50:05 +0200 Original-Received: from localhost ([::1]:35394 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ln2A0-000693-5M for ged-emacs-devel@m.gmane-mx.org; Sat, 29 May 2021 12:50:04 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46030) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ln29E-0005T1-0A for emacs-devel@gnu.org; Sat, 29 May 2021 12:49:16 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:47484) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ln29D-0003ef-4O; Sat, 29 May 2021 12:49:15 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2564 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ln29B-000817-Qs; Sat, 29 May 2021 12:49:14 -0400 In-Reply-To: (message from Aaron Jensen on Sat, 29 May 2021 09:18:07 -0700) 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:270072 Archived-At: > From: Aaron Jensen > Date: Sat, 29 May 2021 09:18:07 -0700 > > On Sat, May 29, 2021 at 2:21 AM Eli Zaretskii wrote: > > > > Compared to what latency without line numbers? 60-80ms is quite a lot > > for redisplay, but I don't really have a clear picture of how that > > works on NS. > > Often around 90-100ms. I don't understand: you get 60-80ms _with_ line numbers and 90-100ms _without_ line numbers? That's the opposite of what I would expect. > As I've described earlier in this thread, turning on line numbers > massively increases the number of calls to > lface_from_face_name_no_resolve And as I've explained to you, "massively" is an exaggeration. The number of face merges increases roughly two-fold when you turn on line numbers. > specifically with faces that are very late in my list of faces. Which faces are those? If they are line-number faces, does it mean that turning on display-line-numbers-mode earlier makes redisplay faster for you? > If I slice that to only include calls from maybe_produce_line_number, > I get 203ms to assq_no_quit. Not sure I understand: 230ms for a _single_ call to assq_no_quit? If not, for how many calls? > This means 37% of the CPU time emacs spends when I'm typing is in > assq_no_quit for face lookup. 37% by itself is not a catastrophe. Redisplay performs many face merges. > So, perhaps the question is, why is assq_no_quit such a hot spot for > me on my machine when there are over 1000 faces in the list to scan? Good question. > Another data point, without the patch: > > (benchmark 500000 '(assoc 'line-number face-new-frame-defaults)) > > On my emacs config: 2.7s > emacs -Q: 0.14s That's 5.4 microseconds per call. How is this consistent with the 230ms figure above? > And with the patch: > > (benchmark 500000 '(gethash 'line-number face--new-frame-defaults)) > > My config: 0.06s > emacs -Q: 0.06s That's not surprising. But what does it tell you about the actual use case which we were discussing? > I'm really not seeing anything mysterious about this, but I don't have > the context you have so I could be missing something. It looks like a > case of O(N) scales worse than O(log n). I just happen to have an N > that is 10x the N with emacs -Q. Linear search should be linear in the number of faces in the list.