On Tue, Dec 19, 2023 at 2:32 PM Jeff Davis <pgsql@j-davis.com> wrote:
>
> On Mon, 2023-12-18 at 13:39 +0700, John Naylor wrote:
> > For now just two:
> > v10-0002 is Jeff's change to the search path cache, but with the
> > chunked interface that I found to be faster.
>
> Did you consider specializing for the case of an aligned pointer? If
> it's a string (c string or byte string) it's almost always going to be
> aligned, right?
That wasn't the next place I thought to look (that would be the strcmp
call), but something like this could be worthwhile.
If we went this far, I'd like to get more use out of it than one call
site. I think a few other places have as their hash key a string along
with other values, so maybe we can pass an initialized hash state for
strings separately from combining in the other values. Dynahash will
still need to deal with truncation, so would need duplicate coding,
but I'm guessing with that truncation check it's makes an optimization
like you propose even more worthwhile.
> I hacked up a patch (attached). I lost track of which benchmark we're
> using to test the performance, but when I test in a loop it seems
> substantially faster.
That's interesting. Note that there is no need for a new
fasthash_accum64(), since we can do
fasthash_accum(&hs, buf, FH_SIZEOF_ACCUM);
...and the compiler should elide the switch statement.
> It reads past the NUL byte, but only to the next alignment boundary,
> which I think is OK (though I think I'd need to fix the patch for when
> maxalign < 8).
Seems like it, on both accounts.