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 09:18:07 -0700 Message-ID: References: <83k0ni6pje.fsf@gnu.org> <83eedq6mvm.fsf@gnu.org> <83zgwd6gk3.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="9022"; mail-complaints-to="usenet@ciao.gmane.io" To: Alan Third , Eli Zaretskii , Aaron Jensen , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat May 29 18:19:56 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 1ln1gq-00025c-2g for ged-emacs-devel@m.gmane-mx.org; Sat, 29 May 2021 18:19:56 +0200 Original-Received: from localhost ([::1]:43698 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ln1gp-0007Yq-3i for ged-emacs-devel@m.gmane-mx.org; Sat, 29 May 2021 12:19:55 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40908) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ln1fO-0006mU-NJ for emacs-devel@gnu.org; Sat, 29 May 2021 12:18:27 -0400 Original-Received: from mail-pj1-x1031.google.com ([2607:f8b0:4864:20::1031]:54971) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ln1fK-0007C8-AZ; Sat, 29 May 2021 12:18:26 -0400 Original-Received: by mail-pj1-x1031.google.com with SMTP id g24so4229577pji.4; Sat, 29 May 2021 09:18:20 -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; bh=dtw0ppXqRGDxagG/QqnDfaVm953zmNdEspZn6lOM3pQ=; b=AhJmT52wA0R6oAFKNnz65xkMIrQpb8xwiHhOvozwM1KpY/wcC95p/IA8okadpP8UGH xiwRi+TtfnZv7A14eG72x90Ly6MB4y/HEUgWoV9ew5XDlutNGX3F68tGrEZ8PSlSkt6X lnYeOkd4+bJ89UN0cyibf0oarq8BHLKvqMuZSMH1P3JzXdWSj9lDPRqvSjFXxNlr8h0u w8tD2dVZiNk9KcWEV1u4xLB2xb4KzKG/x5kdsazZFt2tmd0KiapqP2ZpQvny6jlMpMVx 5rjnzIoutSrLDhUsjHbGuwobrMHCpcU+3zzIFUBIPZ2BZPxi1I2ox0MLfphZPPcLcIww PTQA== 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; bh=dtw0ppXqRGDxagG/QqnDfaVm953zmNdEspZn6lOM3pQ=; b=lHJcEjbgxnbM0eU01uyztGoKVxC6g8PnEUyzEGXT4jBQhn1Bratyund0sTC1AvfzV6 pvTCGB99BNHG+ZUKMDwHz4uvM9zQplFfSx2l9Pm2CAAi4ctEO0LHLOHm881nTuaVuV37 wvzi/WnDSN53IRF6QDfFgUqS/YtOG9wGP9hrIiLJQOYhvGVvT4cgzmakcfAgs8VWUKAK F93KZKqeowgdWJVwJXVM/CREN6zCR82Sp8XSaiIleMHKIxdZfNEfrUEP7En7t06oSjhH qyTk/3T3YvGFwgEAnhTdxlgPOJ7EHFcp3FGDypNz2jp5yFqwy/TwC6qTuTcmn8QMevxk kCVg== X-Gm-Message-State: AOAM5317pHR4MtEY1iAraWB8qMbqguUZb7weFylRhbYftctDCiKvY/Sk 9sSW2ec2MWTqKi6g/2qUZOb+p6pR4UMAbhWE1sbmCCGSgOZW+g== X-Google-Smtp-Source: ABdhPJwXne/rOUDK6aDaLmb4piW4s15gk4CWdjsNUV61bk8g+6BcPaiumntHPWn5chnV9yGPANEIhlRmhV99HJhnCDA= X-Received: by 2002:a17:90b:350a:: with SMTP id ls10mr10415770pjb.181.1622305099315; Sat, 29 May 2021 09:18:19 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::1031; envelope-from=aaronjensen@gmail.com; helo=mail-pj1-x1031.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:270069 Archived-At: On Sat, May 29, 2021 at 2:35 AM Alan Third wrote: > > FWIW, on my Mac I put some timings into the display code and from the > moment we receive a keyDown notification to the moment we hand off the > drawn buffer to the system for display takes around 3-6ms, so unless > Aaron's system is very different from mine, most of that time is spent > in places we can't do much about. 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'm actually measuring using a high speed camera (iphone) and comparing the physical keydown time, so it includes keyboard controller time, USB signal time, OS interrupt handling, monitor pixel latency, etc. Oh and I was mistaken on my face count, that was actually the position of the line-number face. My face count is 1234 at the moment. On Sat, May 29, 2021 at 2:41 AM Eli Zaretskii wrote: > > The question is: is this 3 to 6ms delay affected in any way by turning > on line numbers? If not, then not only don't I understand why line > numbers affect the latency, I also don't understand how come the > number of faces affects that. 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 specifically with faces that are very late in my list of faces. This is a profile of me typing about 10 characters with the profile tree reversed and a lower debug symbol setting (not sure what, i built this with homebrew) so it's not showing macros: https://cln.sh/9Fsiqe If I slice that to only include calls from maybe_produce_line_number, I get 203ms to assq_no_quit. This means 37% of the CPU time emacs spends when I'm typing is in assq_no_quit for face lookup. It also means that 21% of the CPU time emacs spends when I'm typing is in assq_no_quit for face lookup specifically for line numbers. So, line numbers account for 57% of the CPU time spent doing face lookups on my machine. 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? I'm not sure I could answer that, but it's intuitive that the more faces one has, the more time a machine would spend doing linear scans, and when those scans are done a massive number of times, it's not surprising to see them show up on profiles. 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 And with the patch: (benchmark 500000 '(gethash 'line-number face--new-frame-defaults)) My config: 0.06s emacs -Q: 0.06s 500k is roughly how many *extra* calls to lface_from_face_name_no_resolve are made during the scroll up benchmark when line numbers are enabled. 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. Aaron > -- > Alan Third