Обсуждение: simplehash: SH_OPTIMIZE_REPEAT for optimizing repeated lookups of the same key

Patch attached.

The caller could do something similar, so this option is not necessary,
but it seems like it could be generally useful. It speeds things up for
the search_path cache (and is an alternative to another patch I have
that implements the same thing in the caller).

Thoughts?

Regards,
    Jeff Davis

On Mon, Nov 20, 2023 at 06:12:47PM -0800, Jeff Davis wrote:
> The caller could do something similar, so this option is not necessary,
> but it seems like it could be generally useful. It speeds things up for
> the search_path cache (and is an alternative to another patch I have
> that implements the same thing in the caller).

I'm mostly thinking out loud here, but could we just always do this?  I
guess you might want to avoid it if your SH_EQUAL is particularly expensive
and you know repeated lookups are rare, but maybe that's uncommon enough
that we don't really care.

-- 
Nathan Bossart
Amazon Web Services: https://aws.amazon.com

On Mon, 2023-11-20 at 22:50 -0600, Nathan Bossart wrote:
> I'm mostly thinking out loud here, but could we just always do this? 
> I
> guess you might want to avoid it if your SH_EQUAL is particularly
> expensive
> and you know repeated lookups are rare, but maybe that's uncommon
> enough
> that we don't really care.

I like that simplehash is simple, so I'm not inclined to introduce an
always-on feature.

It would be interesting to know how often it's a good idea to turn it
on, though. I could try turning it on for various other uses of
simplehash, and see where it tends to win.

The caller can also save the hash and pass it down, but that's not
always convenient to do.

Regards,
    Jeff Davis

On Mon, Nov 20, 2023 at 10:37:47PM -0800, Jeff Davis wrote:
> It would be interesting to know how often it's a good idea to turn it
> on, though. I could try turning it on for various other uses of
> simplehash, and see where it tends to win.

That seems worthwhile to me.

-- 
Nathan Bossart
Amazon Web Services: https://aws.amazon.com

Hi,

On 2023-11-20 22:37:47 -0800, Jeff Davis wrote:
> On Mon, 2023-11-20 at 22:50 -0600, Nathan Bossart wrote:
> > I'm mostly thinking out loud here, but could we just always do this? 
> > I
> > guess you might want to avoid it if your SH_EQUAL is particularly
> > expensive
> > and you know repeated lookups are rare, but maybe that's uncommon
> > enough
> > that we don't really care.
> 
> I like that simplehash is simple, so I'm not inclined to introduce an
> always-on feature.

I think it'd be a bad idea to make it always on - there's plenty cases where
it just would make things slower because the hit rate is low. A equal
comparison is far from free.

I am not quite sure this kind of cache best lives in simplehash - ISTM that
quite often it'd be more beneficial to have a cache that you can test more
cheaply higher up.

Greetings,

Andres Freund

On Tue, 2023-11-21 at 08:51 -0800, Andres Freund wrote:
> I am not quite sure this kind of cache best lives in simplehash -
> ISTM that
> quite often it'd be more beneficial to have a cache that you can test
> more
> cheaply higher up.

Yeah. I suppose when a few more callers are likely to benefit we can
reconsider.

Though it makes it easy to test a few other callers, just to see what
numbers appear.

Regards,
    Jeff Davis