From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#59347: 29.0.50; `:family` face setting ignored Date: Mon, 12 Dec 2022 18:33:14 +0800 Message-ID: <87o7s8j4id.fsf@yahoo.com> References: <0d1ea3007f532a493429@heytings.org> <83cz9f12bh.fsf@gnu.org> <835yewleyn.fsf@gnu.org> <83tu2b9rlx.fsf@gnu.org> <83k0347gtu.fsf@gnu.org> <83v8mm2ug7.fsf@gnu.org> <83cz8u2d6u.fsf@gnu.org> <831qp93nsc.fsf@gnu.org> <1a7e3acf3578520feda7@heytings.org> <87ilihjsrb.fsf@yahoo.com> Reply-To: Po Lu Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21723"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Eli Zaretskii , monnier@iro.umontreal.ca, 59347@debbugs.gnu.org To: Gregory Heytings Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Dec 12 11:34:11 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1p4g8R-0005UU-7V for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 12 Dec 2022 11:34:11 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p4g8M-0005iS-Cz; Mon, 12 Dec 2022 05:34:06 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p4g8J-0005e9-1R for bug-gnu-emacs@gnu.org; Mon, 12 Dec 2022 05:34:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1p4g8I-0000Ew-PM for bug-gnu-emacs@gnu.org; Mon, 12 Dec 2022 05:34:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1p4g8I-0008Ks-9u for bug-gnu-emacs@gnu.org; Mon, 12 Dec 2022 05:34:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Po Lu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 12 Dec 2022 10:34:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 59347 X-GNU-PR-Package: emacs Original-Received: via spool by 59347-submit@debbugs.gnu.org id=B59347.167084121432031 (code B ref 59347); Mon, 12 Dec 2022 10:34:02 +0000 Original-Received: (at 59347) by debbugs.gnu.org; 12 Dec 2022 10:33:34 +0000 Original-Received: from localhost ([127.0.0.1]:52037 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p4g7p-0008KZ-Tm for submit@debbugs.gnu.org; Mon, 12 Dec 2022 05:33:34 -0500 Original-Received: from sonic314-20.consmr.mail.ne1.yahoo.com ([66.163.189.146]:46409) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p4g7o-0008KR-9A for 59347@debbugs.gnu.org; Mon, 12 Dec 2022 05:33:32 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1670841204; bh=0V8QqgOTTWipi4ugMQVEzr2MJjw7A1OMjubt2X8ax+4=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=cVnYbKX3AVnHjNfQINhvdK2YAptIFlbHA3H9mtE4oUQEGeQ3b5/WS3Ey8bFEn7o8TaaseqeqZObEYH85UlclyWs3VmUxNBWgxejwFuKDeFfZ8sKeh2UeabfKeORzbL5LexlgDV9oh2EhCbI0sxJc+IDIZDFfQhzoQNY2TOOeN/jppdsl52pMEcBJSWx17lM0+Yta499fGJhHBCwXqZD3bPBmKO7+oFYwbSJ82AYcTL/CZyJXvdrcYRmsZGY/sA9MQyV6PsYhBbs28p4oLg7xj6FPRNyc7P15Mw7SA4kuftV5WTK/nIcUJIlbEKXTf7GtSBoNpn5FJ4TdXnDRmFt7CQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1670841204; bh=uwQHPPQPzuJXkErM3bn54ur/VPEqGiKjWz4h/+UQq1R=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=kp76EP8iJm9FoJNLSHqpV6TG92cfNJUtCR/utIT/r4VmoQuemCUuDFEWTSihFXnN5xkPDINoJL3hfN8Wxdv78jMP0NSIZ25zepsJAueaH37O4CQayuJYdKlT5+A8Dqo9bwqhsoiDIosQW1bOrSRSJWxdWkcBWqx9S047chGJnO1s8lO7fAAqZvSCzL5GP1U1UHao1Ztn1bRnalRTNfAL+BQxuaRPso+w0DYxFwFM5yVqmtmPB1X+/cOyT7GzDSSncMNOltH2XCjbBlm/nQMVVdnJyGOvg85ER5EZrGCAJqKzQN3WtvNUdAzcCw34eK63+10d9wtNBpHL8uy3fe19eA== X-YMail-OSG: aQzRJEMVM1kVNpDsFbhFfjsIJisRlhdXYDNDBhpKCpvp_s.ifKD8VYmxdyvRPJ0 3NzbJ90y28P8uscwaL8cZTI0tBeYqoMbD1k71_IglyATqPk6Tw.TEMy7Odq59pYjzwg_5G6rRvQL WQLdz8Lxiv.zFSioo0aF0PrveRgvHbCOv6wokcpcNckNfE.LDD4XCrokEGuDSzdu.U4E700kpUyP DhFmlFdtI7voe7SP2iIvnQAZ2QZOnQMiuo.sWmjTo25tOKo_Dxu.psIGYhr1512ei8VqBwQhe_b5 AAvexb6N3RLA2.h4yJNpXtGTrM.vrbNyrzYexU_3d_oBaCLw7MCKmo_yNOVISBeb_XlBRNCD7AVc U07q9EOVdkP7QxEXN_hK1qjytIFEy1VuUb3ke20UYWEBg7XmXWGFfueCkbvevjpbwL6B5SsFjOdG TNYIe3uOouJpuNN3MSidU.l.jUgWW2hq05fKCW32EpTqWIeTyLhcAxeO615aPY43rtX0wyeXhUXc jjV7RxkGuMpAirS.5vcJURe9dTf4ISX6l9nRldMz.LZyK0GWX6zQ62YgKsEStoAM9fzS5IGxvl0m tOA2HFuLLc7jYuZ47bGRb7E8.eQoJP85e7_7vyJzX2G2IqwIjl8RclSKc_qN0k5A7y3khWc7uFO_ KwcJwyPEsRCz4gRc9eEfpnff_qLbl7Api2N3MCW5bf34Bo_npyCaZKlanK1_w5vLD5c5rdE7cRoA tsNnbzX35b7cDS7e2qdP9g5k6EVNKf9yRawrVBm414t3EtTv9HQaIIB.9ypFxz3dcGCINHgX50Kb L7QIEYVXd1cLWKY2q.NduEGolZypgqxMN2YRtwbjvB X-Sonic-MF: Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.ne1.yahoo.com with HTTP; Mon, 12 Dec 2022 10:33:24 +0000 Original-Received: by hermes--production-sg3-b666c6484-prndz (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 2d6a95f6dc57cdb682f956df2fa05e56; Mon, 12 Dec 2022 10:33:20 +0000 (UTC) In-Reply-To: (Gregory Heytings's message of "Mon, 12 Dec 2022 08:54:16 +0000") X-Mailer: WebService/1.1.20926 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:250691 Archived-At: Gregory Heytings writes: > My measurements indicate that the "improved" code is ~20 slower in an > optimized build, and I care about performance. That's a lot to handle > a variable that is, in fact, a near-constant. And how many microseconds is ``~20x slower''? Do you actually see the drop in performance? You remind me of the people who painstakingly profile GL, and get angry over a drop in performance from ``26450fps'' to ``9300fps'', when the end result is still more than sufficient to match the display refresh. With the following instrumentation: diff --git a/src/xfaces.c b/src/xfaces.c index 88d3a79f8c0..0eced7b7be5 100644 --- a/src/xfaces.c +++ b/src/xfaces.c @@ -6089,8 +6089,15 @@ realize_gui_face (struct face_cache *cache, Lisp_Object attrs[LFACE_VECTOR_SIZE] } if (! FONT_OBJECT_P (attrs[LFACE_FONT_INDEX])) { + unsigned long long t1, t2; + struct timespec timespec; + spec = copy_font_spec (attrs[LFACE_FONT_INDEX]); + clock_gettime (CLOCK_THREAD_CPUTIME_ID, ×pec); + t1 = (timespec.tv_sec * 1000000 + + timespec.tv_nsec / 1000); + /* Unset several values in SPEC, usually the width, slant, and weight. The best possible values for these attributes is determined in font_find_for_lface, called @@ -6117,6 +6124,11 @@ realize_gui_face (struct face_cache *cache, Lisp_Object attrs[LFACE_VECTOR_SIZE] font_unset_attribute (spec, FONT_SPACING_INDEX, QCspacing); font_unset_attribute (spec, FONT_AVGWIDTH_INDEX, QCavgwidth); + clock_gettime (CLOCK_THREAD_CPUTIME_ID, ×pec); + t2 = (timespec.tv_sec * 1000000 + + timespec.tv_nsec / 1000); + fprintf (stderr, "that was: %ull us\n", t2 - t1); + attrs[LFACE_FONT_INDEX] = font_load_for_lface (f, attrs, spec); } if (FONT_OBJECT_P (attrs[LFACE_FONT_INDEX])) all that code takes somewhere between 2 to 4 microseconds to complete for me, in a build with optimizations enabled. I don't know how many faces you think people have to realize, or what kind of 1950s computer you have in mind, but on any reasonably modern computer it will take somewhere around 500,000 to 250,000 faces for this extra code to make a single seconds' difference. > Once again, that variable isn't supposed to be changed by users. It > is there for one purpose: if a user reports a bug about font > selection, it will be possible to ask them to set that variable to > this-and-that value (most probably 0 and most-positive-fixnum) to > check whether Emacs behaves better. > > Of course, brave souls can also try to change it, if they want. No matter whether or not a variable is supposed to be changed by the user, it must not be a bitmask! And in general, it must not be confusing to users. Users are supposed to debug Emacs. > It is not "searching for a symbol through a list with three elements", > it is 12 function calls, each of which traverses a list of three > elements. And how many microseconds is that? How is it significant, compared to the time it takes to send the glyphs in the resulting font off to the X server and wait for a reply? Or to allocate all the colors in the face? Or to simply search through the color cache for all those colors? > The post to which you are replying explains in every possible detail > why that statement is wrong. That you don't have the patience to read > a 300 posts long bug thread is one thing, that you don't have the > patience to read a 100 lines long explanation, and bluntly declare > that it is "nonsense", is another. Then feel free to write a better doc string, instead of outright reverting the change. The only requirement is that it must describe the variable in terms that users can understand, even if it is somewhat vague. > And the purpose of that variable is precisely that: making it possible > to dynamically control an implementation detail. It is _not_ supposed > to be set by users who do not know about the inner workings of the > face code. If users are not supposed to set the variable, then delete it completely. Otherwise, users will set it, and documentation they cannot understand is just asking for trouble.