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 11:22:06 -0700 Message-ID: References: <83k0ni6pje.fsf@gnu.org> <83eedq6mvm.fsf@gnu.org> <83zgwd6gk3.fsf@gnu.org> <83bl8t5vu6.fsf@gnu.org> <83a6od5tqh.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="23130"; 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 20:24:31 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 1ln3dP-0005qM-BZ for ged-emacs-devel@m.gmane-mx.org; Sat, 29 May 2021 20:24:31 +0200 Original-Received: from localhost ([::1]:34422 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ln3dO-00076V-Bs for ged-emacs-devel@m.gmane-mx.org; Sat, 29 May 2021 14:24:30 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34762) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ln3bM-0006D5-1P for emacs-devel@gnu.org; Sat, 29 May 2021 14:22:25 -0400 Original-Received: from mail-pl1-x62b.google.com ([2607:f8b0:4864:20::62b]:37787) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ln3bJ-0001QL-3w; Sat, 29 May 2021 14:22:23 -0400 Original-Received: by mail-pl1-x62b.google.com with SMTP id u7so3182764plq.4; Sat, 29 May 2021 11:22:19 -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=/ClZ8FXUx96urDD7/pjNCrYZpMCJh7TfYjg74GRJLDA=; b=d9ReM3ffkfZoUtL/CQkmiHHwmC4U46PmqZcwB+9gCuFSsAmNCXOlzrN1mK76MkxSCg y+Fe2tsSkhBcf8/R626ReSj+4ekIi//0TIeKd97W024if+0btyqyxeNMlGZT0VD9ytCS IiXh6UgPPMjNF2N79pO0X5eV3GKyDWsCaPCKbxT9IcjbFiOlgYAq1lQi1CNQ4meHu8oS NxvYqx7+DIbw+/lec8rLm8hNwEkYmDlPCY07Ao0311gLiOyKccVVHn1s4i5z+/moM/XO IJD4tYbOSG3TczPC87iBm36rDJo5xIdEEzMHf4/3uiYZZOj1lOaASIhVUDlir+Eq4waD 258w== 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=/ClZ8FXUx96urDD7/pjNCrYZpMCJh7TfYjg74GRJLDA=; b=KNHcon+WYEIs9kPjl5pxdz4aBDpVWU2qe8Cp5nX/iNSpg3rvZwB/t9tUTyrpTMOxna W+vHEiiCfycVNjEHApJjYad1IaO/tyjb/aIvc5MuXk3SZG3A+L/S2Z3j3v0fhbxbgce7 WP5t4vZ6JlyEnDnI0VL868I1a4YMo3rQrtHWApLnIojQgvyfLkRj8FiHcb8/cWfjQD+V BxdyvtHJW/qUjT7e/05Vdsu29AtppSvCnoo3grtakWH2bHFCBTNRcp9Kjj1RKMO7l5aK r2OVl5CgV031gV8jZA5g/QWegxHv7URPAt3e0BxLGMLKYI85DoGlnwA1kOMOXqhFkJGk Kd3Q== X-Gm-Message-State: AOAM5301A5XYuvhpYpPqFC7jVseD8fISMRIJa9tfg3r338J4HMAXEoi+ ETM7FyhtDGV9gxlCGKpaCRcs2ercmcuLZmQV+axsnt33MylbOg== X-Google-Smtp-Source: ABdhPJxpGs6tEhjQTDv36xlrzCxF94+/gXbQkA+eA/Y2Z0lNbCXkUxey3qYg7hgtQcBfZZttAyPk2/uj0S9PLxqvTRE= X-Received: by 2002:a17:903:31c3:b029:ed:6f74:49c7 with SMTP id v3-20020a17090331c3b02900ed6f7449c7mr13319618ple.12.1622312537535; Sat, 29 May 2021 11:22:17 -0700 (PDT) In-Reply-To: <83a6od5tqh.fsf@gnu.org> Received-SPF: pass client-ip=2607:f8b0:4864:20::62b; envelope-from=aaronjensen@gmail.com; helo=mail-pl1-x62b.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:270085 Archived-At: On Sat, May 29, 2021 at 10:34 AM Eli Zaretskii wrote: > > > 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?) It was with the patch. I was primarily reporting that for Alan's benefit as he and I had been discussing those latency numbers. > 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. I didn't, because I hadn't measured it yet. I just measured it and it's very similar. This measurement technique is very imprecise, so I have to take several measurements. I can't measure a difference between line numbers and not when the hash patch is applied. > > > > 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? I did not say this. 500k times, according to the benchmarks I provided, take over 2s. It's only 15ms to do 500k _hash lookups_. > > 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? My theme is set up like this: https://github.com/aaronjensen/nano-emacs/blob/master/nano-theme.el I don't know if I'm doing something wrong in there, I copied it from the nano project. I know it's atypical to not use a theme. > > > > 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? Yes, a linear effect compounded by a large number of calls. That said, it looks like the effect is 2x what I'd expect given the difference between face counts. So yes, there may be something else at play. I'd have to actually put a count in assq_no_quit to see if it's being called more times than I'd expect. About perceiving typing latency, have you read this article: https://pavelfatin.com/typing-with-pleasure/ It's what finally helped me understand what I was perceiving many years ago. Aaron