From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Spencer Baugh Newsgroups: gmane.emacs.devel Subject: Re: [PATCH 0/7] Cleanups and tests for DEFVAR_PER_BUFFER variables Date: Thu, 01 Apr 2021 14:13:50 -0400 Message-ID: <87a6qhyish.fsf@catern.com> References: Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="10174"; mail-complaints-to="usenet@ciao.gmane.io" Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Apr 01 20:18:19 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 1lS1tV-0002HW-Mp for ged-emacs-devel@m.gmane-mx.org; Thu, 01 Apr 2021 20:18:13 +0200 Original-Received: from localhost ([::1]:38046 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lS1tU-000576-IX for ged-emacs-devel@m.gmane-mx.org; Thu, 01 Apr 2021 14:18:12 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60144) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lS1pY-0002px-Bi for emacs-devel@gnu.org; Thu, 01 Apr 2021 14:14:11 -0400 Original-Received: from venus.catern.com ([68.183.49.163]:36492) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lS1pQ-00032d-Gs; Thu, 01 Apr 2021 14:14:08 -0400 Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=98.7.229.235; helo=localhost; envelope-from=sbaugh@catern.com; receiver= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=catern.com; s=mail; t=1617300838; bh=HnfDh6vy3h8/kwjNSughQ6Y25/OS8uI3wO+OQbDHxLY=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=Z2oDHZuH90A07rL6dbrd80YodHbJvXIr4WbjmFE7GGMN6xRAtcWz/x325nUqEucI0 SMcN+dVCWFTOilPTbtjMPmjX1F7tXFC/R7JZlHibMwdcsgLB3tiMFzQP9HQM6N4MWo ZGUUXP8GuKrboP6D4yqonY7Lrua6dW3h3AMqcfuY= Original-Received: from localhost (cpe-98-7-229-235.nyc.res.rr.com [98.7.229.235]) by venus.catern.com (Postfix) with ESMTPSA id 48B692E6F45; Thu, 1 Apr 2021 18:13:58 +0000 (UTC) In-Reply-To: Received-SPF: pass client-ip=68.183.49.163; envelope-from=sbaugh@catern.com; helo=venus.catern.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, 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:267272 Archived-At: Eli Zaretskii writes: > I'd prefer to pick up where we left off back then. The main issue > left unresolved in the past discussion was the potential slowdown of > simple accesses to buffer-local vars due to your proposal. Can we > please have benchmarks for that, so we could decide whether the > tradeoff is worth it? It's quite possible that the performance > aspects could affect the code changes, so even uncontroversial > cleanups should perhaps wait until we have figured out the more > important aspects of these changesets. 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 | My original changes imposed about a 1-2% slowdown on an unmodified Emacs. That's unacceptable, so I made a further change to only check Qunbound for vars where it was actually necessary. That makes the performance comparable to an unmodified Emacs, so I think in terms of performance that should put this in a good state. To statically avoid checking Qunbound for vars where it's not necessary, we need to use separate syntax for accessing BVARs that have defaults and BVARs that don't have defaults. Only BVARs that have defaults need a Qunbound check. (We could use the same syntax for both, but it would require X macros which Eli disliked earlier) I see three general options for the syntax for accessing each kind of var: | | 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? I went with option 3 for the large refactoring, but if it's OK in terms of coding style I think option 1 is nicer. 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. I'll post my updated patches after I know which syntax people would prefer. (The change compared to the earlier patches is pretty small, besides adjusting all the BVAR usages to use the new syntax)