On Fri, Aug 05, 2022 at 11:02:15AM +0700, John Naylor wrote:
> That is a good point. Maybe potential helpers in simd.h should only deal
> specifically with vector registers, with it's users providing C fallbacks.
> I don't have any good ideas of where to put the new function, though.
I moved it to src/include/port for now since that's where files like
pg_bswap.h live.
> Hmm, I didn't know about those. lfind() is similar enough that it would
> make sense to have pg_lfind32() etc in src/include/port/pg_lsearch.h, at
> least for the v4 version that returns the pointer. We already declare
> bsearch_arg() in src/include/port.h and that's another kind of array
> search. Returning bool is different enough to have a different name.
> pg_lfind32_ispresent()? *_noptr()? Meh.
>
> Having said all that, the man page under BUGS [1] says "The naming is
> unfortunate."
I went ahead and renamed it to pg_lfind32() and switched it back to
returning the pointer. That felt the cleanest from the naming perspective,
but as Andres noted, it might not be as fast as just looking for the
presence of the element. I modified my small testing program to perform
many searches on small arrays, and I wasn't able to identify any impact, so
perhaps thіs is good enough.
Thoughts?
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com