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 v2 00/16] Speeding up DEFVAR_PER_BUFFER Date: Sun, 22 Nov 2020 18:12:29 +0200 Message-ID: <837dqdxtea.fsf@gnu.org> References: <20201119153814.17541-1-sbaugh@catern.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35709"; mail-complaints-to="usenet@ciao.gmane.io" Cc: arnold@tdrhq.com, Richard Stallman , sbaugh@catern.com, emacs-devel@gnu.org, monnier@iro.umontreal.ca, dgutov@yandex.ru To: Spencer Baugh Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Nov 22 17:14:32 2020 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 1kgs0W-00099X-1y for ged-emacs-devel@m.gmane-mx.org; Sun, 22 Nov 2020 17:14:32 +0100 Original-Received: from localhost ([::1]:54018 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kgs0V-0005yD-3i for ged-emacs-devel@m.gmane-mx.org; Sun, 22 Nov 2020 11:14:31 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60620) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kgrzA-0005Lr-W7 for emacs-devel@gnu.org; Sun, 22 Nov 2020 11:13:09 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:46401) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kgrz9-0008RV-LH; Sun, 22 Nov 2020 11:13:07 -0500 Original-Received: from [176.228.60.248] (port=3471 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kgrye-00039X-Ok; Sun, 22 Nov 2020 11:12:37 -0500 In-Reply-To: (message from Spencer Baugh on Sat, 21 Nov 2020 21:34:29 -0500) 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:259620 Archived-At: > From: Spencer Baugh > Date: Sat, 21 Nov 2020 21:34:29 -0500 > Cc: Spencer Baugh , Arnold Noronha , > Stefan Monnier , Dmitry Gutov > > This patch series reworks access to Lisp_Object fields in struct > buffer. The primary motivation is performance of DEFVAR_PER_BUFFER > Lisp variables, but this also removes several now-unnecessary pieces > of metadata and generally simplifies things. > > Relative to v1, this patch series now performs a larger refactoring of > struct buffer field access, which should provide for good performance > while keeping the access method uniform. I've also corrected style > issues and bugs pointed out in review, and added some testing for > buffer-local let variables. (Thanks Stefan for the review, and the > tests you added in the fix for bug#44733, both were quite helpful.) > > It's possible to provide further performance improvements [...] Thanks, but could you perhaps provide a more detailed overview of the general idea of the changeset? It is not easy to glean that from 16 patches, each one describing only the details of its narrow goal. Please include in the more detailed overview indications what parts of the series are really needed to speed up buffer-local variables and which are cleanups in the areas of the changes not directly related to speeding things up. > I have an idea which would allow avoiding the mass change, if that's > desired, which also has some additional benefits. We could define > getter functions (marked as inline) for each Lisp_Object field, and > have BVAR call those field-specific getter functions by forming the > name of the getter through token pasting. The boilerplate of the > getters would be kept under control by using an X macro to define both > the fields in struct buffer and the getters. Something like: > > #define FIELD_LIST \ > C_FIELD(name) \ > C_FIELD(filename) \ > ... > LISP_FIELD(mode_line_format) \ > ... > > And then "instantiating" FIELD_LIST twice in two different contexts to > define the Lisp_Object fields and the getters. I don't think I have a clear idea of what will this mean in practice. Can you show an example of its usage? > Regardless of what approach we take, at least some level of > benchmarking will be necessary. Is there an established benchmark > suite for these kinds of changes? Is benchmark-run what you are after? Or are you asking what use cases of buffer-local bindings to use inside the benchmark? If the latter, then I guess some simple example with binding case-fold-search followed by some regexp search would do, if you do that with various numbers of live buffers in the session. Thanks.