[PATCH v2 00/16] Speeding up DEFVAR_PER_BUFFER

[Spencer Baugh]

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, although
the current state of the patch series has minimal overhead, and the
uniformity is somewhat appealing.

If we do need to completely remove the overhead, we could do a mass
change to all the uses of BVAR, to introduce separate, maybe,
BVAR_LISP and BVAR_C macros, for fields which need fallback and fields
which don't.  I wasn't sure whether that would be acceptable.

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.  This would have some
additional benefits:
- it would make it a lot easier to tell which fields are C-only and
  which fields are accessed from Lisp
- we can attach more metadata to the individual fields
- we could also generate the existing hand-written setters from these
  macros

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?

(My commit messages are still not in ChangeLog style - sorry - with 16
patches in the series right now, and having not yet personally figured
out a good magit-integrated way to generate ChangeLog-appropriate
messages, I figured I'm better off adjusting the commit messages at
the end of the review process, rather than continually throughout. If
anyone has a recommendation for ChangeLog generation that is
integrated with magit, that would be welcome - I haven't found
anything yet...)

Spencer Baugh (16):
  Add a test for let-binding unwinding
  Assert not local-variable-p after setq in let_default binding
  Stop checking the constant default for enable_multibyte_characters
  Take buffer field name in DEFVAR_PER_BUFFER
  Add BVAR_DEFAULT for access to buffer defaults
  Use bset_* functions instead of BVAR
  Take offset not idx in PER_BUFFER_VALUE_P
  Combine unnecessarily separate loops in buffer.c
  Add and use BUFFER_DEFAULT_VALUE_P
  Add and use KILL_PER_BUFFER_VALUE
  Assert that PER_BUFFER_IDX for Lisp variables is not 0
  Rearrange set_internal for buffer forwarded symbols
  Get rid of buffer_permanent_local_flags array
  Remove unnecessary Qunbound check
  Remove local_flags array in struct buffer
  Remove usage of buffer_local_flags

 lisp/bindings.el       |   3 +-
 src/buffer.c           | 417 ++++++++++++-----------------------------
 src/buffer.h           | 145 ++++++--------
 src/category.c         |   4 -
 src/category.h         |   2 +-
 src/data.c             |  82 ++------
 src/fileio.c           |  12 +-
 src/pdumper.c          |   3 -
 src/print.c            |   6 +-
 src/process.c          |  15 +-
 src/syntax.c           |   4 -
 src/syntax.h           |   2 +-
 src/window.c           |   5 +-
 test/src/data-tests.el |  24 ++-
 14 files changed, 228 insertions(+), 496 deletions(-)

-- 
2.28.0