From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Aaron Jensen Newsgroups: gmane.emacs.devel Subject: Re: macOS metal rendering engine in mac port Date: Sat, 29 May 2021 10:05:51 -0700 Message-ID: References: <83k0ni6pje.fsf@gnu.org> <83eedq6mvm.fsf@gnu.org> <83zgwd6gk3.fsf@gnu.org> <83bl8t5vu6.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30103"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Alan Third , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat May 29 19:07:27 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 1ln2Qo-0007hX-TD for ged-emacs-devel@m.gmane-mx.org; Sat, 29 May 2021 19:07:27 +0200 Original-Received: from localhost ([::1]:47168 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ln2Qn-0006gX-W0 for ged-emacs-devel@m.gmane-mx.org; Sat, 29 May 2021 13:07:26 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49108) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ln2PX-0005uZ-Ml for emacs-devel@gnu.org; Sat, 29 May 2021 13:06:07 -0400 Original-Received: from mail-pg1-x52f.google.com ([2607:f8b0:4864:20::52f]:46635) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ln2PV-0006dz-JH; Sat, 29 May 2021 13:06:07 -0400 Original-Received: by mail-pg1-x52f.google.com with SMTP id n12so1749708pgs.13; Sat, 29 May 2021 10:06:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ydR7QY1Z8BTc/vvZgvAwMyECQwIWPeEAEw2qEfpgVHY=; b=huJ5R0QtkYDeWktcNR7CvwybHpvWF5+A9I5KrawGsm/RUbj+uEq69NeGLRyJveTQz4 OSpID/WYBg1Y83awwKGHOgzZxhi6tdxrHFlSilN5XZ0rCcWkuIdUsTnRlSCLHWgnEjlB OqZo75E8j54eMM1rVMSGGJIVIdNAUIiGwQ0rd2zAKIWxjvEuBc6/acsvj3iIFWUDp7IN HVYLlU0caTKPw/WbAxP0IzRiRJFRPhrgmVlqEqLOdA48FweqGGYC+mx3kSDxsBW9DSww vAPNfa+nyLqnQkkKWfqOJmwcqZHtIiySSaEtUkQ+EAfZvKwp2O9AgKs7vQlq7J3OVaxh dcIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ydR7QY1Z8BTc/vvZgvAwMyECQwIWPeEAEw2qEfpgVHY=; b=jB8VgC2wrpTMKB6u0z4b1yVJpMkeybThqZs9fkTQgjafC5U+/GOsXqS6W7khFlDKUU RrGPEhjufOWvN2YCAB8HLS3qu2P/i11jQtc60UXOAa/dfW7IVPPtPHM0WwTu5Q8eN5q+ b1c5XkbYzvnLdCaJel+f1Rsz5t3C9usG3DzkcYLkunVxLEp2lbTc2x8EfvxIr74fzHs+ 4mUrNmGbsfsC76PvyJk1vtl6+67F0j/iW5iBxsZbyAGdDiz0i9NMQJvOJnQQ4paWQovB w5E8B52Tv96yWjScCF5SUEnRrHEu0kay7paKqAU0DfK5IMZBW0xb7eqF7Uy8nTn8StKo SxUA== X-Gm-Message-State: AOAM5319Zx/5yI3BfpE0eAPhYnu2zDWd3zfb1mRxRKjHRDtx1TQNAUxt ObObu8mtifysqbpV8assJI0h6GmwME6F0uvQODR46AtSB4ePNA== X-Google-Smtp-Source: ABdhPJxGRfD+qOREaQKKCA9WxyBQKvoYYsjiQ9c1lz0FdwNiIcvqmxtbeR1LLgAFRuaL5ROiNWSj1iw1fmIO4UmcFSg= X-Received: by 2002:a62:c541:0:b029:2e8:c7c7:d96e with SMTP id j62-20020a62c5410000b02902e8c7c7d96emr9286020pfg.26.1622307963077; Sat, 29 May 2021 10:06:03 -0700 (PDT) In-Reply-To: <83bl8t5vu6.fsf@gnu.org> Received-SPF: pass client-ip=2607:f8b0:4864:20::52f; envelope-from=aaronjensen@gmail.com; helo=mail-pg1-x52f.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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:270075 Archived-At: 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. > > 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. > > 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? Yes, line number faces. You mean later so that they're nearer to the head of the list? I'm not sure how to test that as the faces get added even w/o enabling line number mode afaict. I also don't know how to modify a frame's face alist and when I tried modifying face-new-frame-defaults and creating a new frame it didn't appear to make a difference. > > 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? No. I don't know how many, but some multiple of 500k. I haven't added a count printer in there yet. > > 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. Well, it's worth mentioning that I'm being persnickety here. Most people probably wouldn't notice the latency difference, but I can feel it and it's frustrating. Here is a profile from a single key press using my config w/o the patch: https://cln.sh/HqVzJv 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. > > 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? Because, as I mentioned below, 500k is the same number of times lface_from_face_name_no_resolve is called, which is the thing that's calling assq_no_quit. > > 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? It tells me that in the scroll benchmark I add over 2s to my time just because of face merging and most of that time is due to enabling line numbers. > > 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.