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: Mon, 24 May 2021 08:32:35 -0700 Message-ID: References: <831r9xjrho.fsf@gnu.org> <5754E85B-9840-416B-B9C1-E6B2B1FC0114@gnu.org> <80A25FCA-2CF4-433F-B82F-4B37ED5BC6DC@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3149"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Alan Third , YAMAMOTO Mitsuharu , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon May 24 17:36:29 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 1llCd2-0000cw-Vl for ged-emacs-devel@m.gmane-mx.org; Mon, 24 May 2021 17:36:28 +0200 Original-Received: from localhost ([::1]:39874 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1llCd2-0007v8-2j for ged-emacs-devel@m.gmane-mx.org; Mon, 24 May 2021 11:36:28 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57596) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1llCZZ-00035i-Sp for emacs-devel@gnu.org; Mon, 24 May 2021 11:32:53 -0400 Original-Received: from mail-pl1-x62c.google.com ([2607:f8b0:4864:20::62c]:39803) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1llCZY-0003bu-3M; Mon, 24 May 2021 11:32:53 -0400 Original-Received: by mail-pl1-x62c.google.com with SMTP id t9so6350192ply.6; Mon, 24 May 2021 08:32:47 -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:content-transfer-encoding; bh=MPP6YQQY4DLS6vuU54yirXx8C2uhDQQG35dn517ixBk=; b=jtsmQIVJ5GKSuEcGwAZfEXsvbyKRucDhTBxEqHaCrcFxtcZ5Gqd8iumVVOlbqvFbhF LhcBVdN/dASOqPWnvpJ8mkJIxYDW0YcSUPV74GMAqH9v12+FRaft1yJIVC07A7n+J0ot uo3qU/o5eQEEe3UAwjQE6xtjdNHkhkZJ1TK5lqkiR6rjuQBXQJePyayc/ZuqGOOMhtiE XoMgKgD7buvP88hypd5HlzDsQs1zIQT9a8OtoDArhEP3Z5m/9/VVr4TQibENOD63fZS1 zZTcbszU7Zfj0siivJ+MpIPjVtgHD71E02N+ApgBVLd5/vRI+jlxnwO6zO80unNm2XR3 nvkg== 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:content-transfer-encoding; bh=MPP6YQQY4DLS6vuU54yirXx8C2uhDQQG35dn517ixBk=; b=eoWzamFgi49Oo/9ARRqwq7MygEQs6IfgeRu0k4JaY3f9k625HIIt6oNFb+shZRbgCB S5BCNUzs6oKVTvdW/UC3Cw4AmNBiAUCXJWbMkFWgy9rNolMCe87mSbnrCPj0Pg3iE/aU G0dE2Rn1r2G+fJ+3flcQT8uhCzVLYkLnnpObtmCzC7HjXpeGujP7ALZRduN4GSgvtQEY 1am67nRcEPoHDp+OWWNIizA+Mrmy7Z7sklnzU8kuyZbp+KjD1KXbd0m28pbAgXLZTl+q rKa9FSZe7PgYpgnUOLsdyytYl3mBHCi/0WzIzs1zjyClRRnzjomz+nodBGWcRp7j9OJ5 26mA== X-Gm-Message-State: AOAM533zKwKeFvL9Pj4i7NSUUSDz8nyqbJXNXxNj9sCLFbh/Pp7W+m9w ulynw7oGO2ULDNq50f6GFd1bHvuL+suXPGpenGE0IBj++0dpsA== X-Google-Smtp-Source: ABdhPJwhLPQRsrFp4rKDdedJSBuOennncGdzTDZWVpAfAjGQhrbR0wrgb6eDnYM7HO/613G/TsfeFevZAanBkL/R70Q= X-Received: by 2002:a17:90a:9511:: with SMTP id t17mr25414677pjo.108.1621870366431; Mon, 24 May 2021 08:32:46 -0700 (PDT) In-Reply-To: <80A25FCA-2CF4-433F-B82F-4B37ED5BC6DC@gnu.org> Received-SPF: pass client-ip=2607:f8b0:4864:20::62c; envelope-from=aaronjensen@gmail.com; helo=mail-pl1-x62c.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:269767 Archived-At: On Mon, May 24, 2021 at 1:48 AM Eli Zaretskii wrote: > > On May 24, 2021 11:07:42 AM GMT+03:00, Aaron Jensen wrote: > > On Mon, May 24, 2021 at 12:37 AM Eli Zaretskii wrote: > > > > > > Why does it look suspect to you? Don't you also see the same code > > called to process the other faces in the buffer? > > > > What looks suspect is that the exact same call is made so many times > > for the exact same faces and that call gets slower proportional to the > > number of faces you have because of the linear search. Fewer faces =3D= =3D > > less work, and when something is called so many times it may be worth > > further optimization or caching. > > But we do the same for every face in the buffer, not just for the line-nu= mber face. When you turn on the line-numbers display, a single face gets a= dded to the faces used by buffer text -- the font-lock faces each major mod= e uses. So how come adding just one face to the dozen of others has such e= ffect? It's not the extra face. It appears that enabling line numbers calls merge_faces for those two faces a significant number of times. See below. > You are right that there are better ways than linear search to look up a = face's attributes by its symbol, and there is a patch in the works to do ju= st that. But the puzzle here is elsewhere. Especially since you report si= gnificant slowdown due to line numbers in "emacs -Q" as well. Awesome! > IOW, what puzzles me is not the difference between "emacs -Q" and your cu= stomizations, what puzzles me is the difference betwen with and without the= line numbers, in the same basic configuration. It cannot be explained by = the length of the frame's face alist alone because in both cases that lengt= h is almost identical: you add one face to the list of hundreds. Agreed, I was only pointing out the length compounding things because I made the likely incorrect assumption that the number of times merge_faces was called when line numbers are turned on was expected. > How many times is it called with line numbers turned off, and what is the= increase in the number of calls due to line numbers in percents? Does it = come anywhere near the slowdown shown in your benchmarks? With it turned off, merge_faces was called 40 times. lface_from_face_name_no_resolve was called 143,308 times. With it on, merge_faces was called 147,882 times and lface_from_face_name_no_resolve was called 661,238 merge_faces: 369705% more calls lface_from_face_name_no_resolve: 461% more calls I'll respond to your second email separately.