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 20:34:46 +0300 Message-ID: <83a6od5tqh.fsf@gnu.org> References: <83k0ni6pje.fsf@gnu.org> <83eedq6mvm.fsf@gnu.org> <83zgwd6gk3.fsf@gnu.org> <83bl8t5vu6.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39236"; 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 19:35:33 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 1ln2s0-0009ws-SX for ged-emacs-devel@m.gmane-mx.org; Sat, 29 May 2021 19:35:32 +0200 Original-Received: from localhost ([::1]:33032 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ln2rz-0001Di-Th for ged-emacs-devel@m.gmane-mx.org; Sat, 29 May 2021 13:35:31 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54386) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ln2rC-0000SN-MG for emacs-devel@gnu.org; Sat, 29 May 2021 13:34:46 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:49020) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ln2rB-0005Lk-EF; Sat, 29 May 2021 13:34:41 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:1391 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 1ln2r9-0005D8-RW; Sat, 29 May 2021 13:34:41 -0400 In-Reply-To: (message from Aaron Jensen on Sat, 29 May 2021 10:05:51 -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:270079 Archived-At: > From: Aaron Jensen > Date: Sat, 29 May 2021 10:05:51 -0700 > Cc: Alan Third , emacs-devel@gnu.org > > On Sat, May 29, 2021 at 9:49 AM Eli Zaretskii wrote: > > > > > 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. > > Ugh, my reading comprehension is off this morning. That was the > without _patch_ timing I shared. Turning off line numbers when the > patch is enabled likely won't make a difference. I can't measure that > right now. I think we might be mis-communicating. You said: > Oh, and even with my config, with line numbers, in a ruby file, I'm > seeing 60-80ms latency with my measuring app. That's quite a bit > better. (Was this with or without the hash patch applied?) In response I asked: > 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. I wanted to know the latency _without_ line numbers in the same setup where with line numbers you see 60-80ms. I'm not sure what you wrote above answers that question. > > > 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. > > 4.5x more calls to lface_from_face_name_no_resolve. Exaggeration or > not, it's significant. Its being significant is what surprises me. The linear search in assq_no_quit should be very fast, as it requires just a few machine instructions per member. You yourself say your profile says it takes 15ms to call that function 500k times. How can extra 15ms be so significant? > It's reversed, but you can see 15ms spent in assq_no_quit. For some > reason, that's enough to put it right over the edge of what I can feel > when I type. I don't understand this. I think there's some other factor at work here. Is it possible that many of the 1200 faces you have inherit from other faces, perhaps recursively? > > > 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. > > Well, to be precise, it's linear in the position of the thing found, > which is relevant when most of the calls are for the same 2 elements. But if these faces are always at the same place near the end of the list, then adding more faces should indeed produce a linear effect, right?