From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: [PATCH 0/7] Cleanups and tests for DEFVAR_PER_BUFFER variables Date: Thu, 01 Apr 2021 21:51:57 +0300 Message-ID: <83sg49g7n6.fsf@gnu.org> References: <87a6qhyish.fsf@catern.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21266"; mail-complaints-to="usenet@ciao.gmane.io" Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Spencer Baugh Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Apr 01 20:53:22 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 1lS2RV-0005O0-VE for ged-emacs-devel@m.gmane-mx.org; Thu, 01 Apr 2021 20:53:21 +0200 Original-Received: from localhost ([::1]:48232 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lS2RU-0005we-VU for ged-emacs-devel@m.gmane-mx.org; Thu, 01 Apr 2021 14:53:20 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41438) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lS2QU-0005UL-GP for emacs-devel@gnu.org; Thu, 01 Apr 2021 14:52:18 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:59955) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lS2QT-0008O1-VQ; Thu, 01 Apr 2021 14:52:17 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4020 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lS2QS-0004jd-Pb; Thu, 01 Apr 2021 14:52:17 -0400 In-Reply-To: <87a6qhyish.fsf@catern.com> (message from Spencer Baugh on Thu, 01 Apr 2021 14:13:50 -0400) 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:267275 Archived-At: > From: Spencer Baugh > Cc: emacs-devel@gnu.org, monnier@iro.umontreal.ca > Date: Thu, 01 Apr 2021 14:13:50 -0400 > > OK, I ran some basic benchmarking. Specifically, I ran > > (defun shr-benchmark () > (let ((gc-cons-threshold 800000000)) > (message "shr-benchmark result: %s" > (benchmark-run 100 > (dolist (file (directory-files (ert-resource-directory) nil "\\.html\\'")) > (shr-test (replace-regexp-in-string "\\.html\\'" "" file))))))) > > out of shr-tests.el. > > My results (each from running emacs -f shr-benchmark 10 times and > discarding the first 2 results): > > | Unmodified Emacs | 2.265s | > | With original changes | 2.295s | > | Avoid unnecessary Qunbound checks | 2.266s | Thanks, that's encouraging. But we need a few more benchmarks, I think. One of them should be for redisplay, as it's a performance-critical part of Emacs, and it accesses buffer-local variables quite a lot. So something like a benchmark of scrolling through xdisp.c one line at a time in an interactive session would probably give us an idea. Another benchmark we frequently use is to remove all *.elc files and then time "make" which byte-compiles them all. > | | Var with default | Var without default | > |------------+------------------------------+--------------------------| > | Status quo | BVAR (buf, field) | BVAR (buf, field) | > | Option 1 | BVAR (buf, field) | buf->field | > | Option 2 | BVAR (buf, field) | BVAR_DIRECT (buf, field) | > | Option 3 | BVAR_OR_DEFAULT (buf, field) | BVAR (buf, field) | > > (The specific names for BVAR_DIRECT or BVAR_OR_DEFAULT don't matter, > we can make them shorter if we want). > > What do people prefer? Either 2 or 3 (perhaps with some slightly different names: maybe none of the new macros should inherit the old name?). > In any case we should ensure that we can't accidentally, for example, > use BVAR_DIRECT on a field that actually has a default. This should > be easy enough by just naming the fields slightly differently. Not sure what you mean by naming differently, but yes, we need to detect incorrect usage at compile time, at least in the build with "--enable-checking". Thanks.