Re: [PATCH] Optimize json_lex_string by batching character copying

On Wed, Aug 24, 2022 at 12:15 AM Nathan Bossart
<nathandbossart(at)gmail(dot)com> wrote:
>
> On Tue, Aug 23, 2022 at 01:03:03PM +0700, John Naylor wrote:
> > On Tue, Aug 23, 2022 at 10:32 AM Nathan Bossart
> >> Here's a new version of the patch with the 32-bit changes and calls to
> >> lfind() removed.
> >
> > LGTM overall. My plan is to split out the json piece, adding tests for
> > that, and commit the infrastructure for it fairly soon. Possible
> > bikeshedding: Functions like vector8_eq() might be misunderstood as
> > comparing two vectors, but here we are comparing each lane with a
> > scalar. I wonder if vector8_eq_scalar() et al might be more clear.
>
> Good point. I had used vector32_veq() to denote vector comparison, which
> would extend to something like vector8_seq(). But that doesn't seem
> descriptive enough. It might be worth considering vector8_contains() or
> vector8_has() as well. I don't really have an opinion, but if I had to
> pick something, I guess I'd choose vector8_contains().

It seems "scalar" would be a bad choice since it already means
(confusingly) operating on the least significant element of a vector.
I'm thinking of *_has and *_has_le, matching the already existing in
the earlier patch *_has_zero.

--
John Naylor
EDB: http://www.enterprisedb.com