Re: [PATCH v2 00/16] Speeding up DEFVAR_PER_BUFFER

[Eli Zaretskii]

> From: Spencer Baugh <sbaugh@catern.com>
> Cc: emacs-devel@gnu.org, arnold@tdrhq.com, monnier@iro.umontreal.ca,
>  dgutov@yandex.ru, Richard Stallman <rms@gnu.org>
> Date: Sun, 22 Nov 2020 11:28:27 -0500
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> > 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.
> 
> Patch 1 and 2 are tests; patch 15 is the speed-up change. Patches 3
> through 14 all change the existing abstractions so that patch 15 can be
> small, and should have no impact. Patch 16 is a followup further cleanup
> enabled by 15. Only 15 should have any meaningful performance impact.

Thanks, but I would also like to hear more about patches 3 to 14, and
how they fit into the overall idea of the speedup change.  Could you
please elaborate on that?  I'm not an expert on this stuff, and I'd
like to understand the idea better, so that I could assess each part
in the context of its place in the overall scheme of this changeset.
I'm sure others could also benefit from hearing more details.

TIA.

> In our case, it would be something like
> struct buffer {
> #define C_FIELD(field) Lisp_Object field;
> #define LISP_FIELD(field) Lisp_Object field;
>        FIELD_LIST
> #undef C_FIELD
> #undef LISP_FIELD
> }
> 
> #define C_FIELD(field) Lisp_Object bget_ ## (struct buffer *b) \
> { return b->field ## _; }
> #define LISP_FIELD(field) Lisp_Object bget_ ## (struct buffer *b) \
> { return bvar_get(b, offsetof(struct buffer, field)); }
>        FIELD_LIST
> #undef C_FIELD
> #undef LISP_FIELD
> 
> #define BVAR(b, field) bget_ ## field (b)

Thanks.  I think this looks like too complex and hard to read for the
benefit it brings.  What do others think about using this technique?

> Ah, no, I mean benchmarking the rest of Emacs to see the impact.

Perform some heavy text-process task many times and benchmark that, I
guess.  Rendering HTML by shr.el comes to mind.

> (benchmark-run 500000 (let ((case-fold-search nil)) (string-match "" "")))
> ; unpatched emacs: (0.6872330339999999 0 0.0)
> ; patched emacs: (0.608068564 0 0.0)
> (setq my-buffer-list nil)
> (dotimes (idx 1000) (push (get-buffer-create (format "test-buffer:%s" idx)) 
> my-buffer-list))
> 
> (benchmark-run 500000 (let ((case-fold-search nil)) (string-match "" "")))
> ; unpatched emacs: (18.591189848 0 0.0)
> ; patched emacs: (0.5885462539999999 0 0.0)

I've seen those, but they are too synthetic to be interesting.  I
meant a real regexp search, in a large buffer.