Further fix on fastArrayCache has

[eileenmcnaughton]

Overview

Further fix on fastArrayCache has

We recently got a good performance boost on accessing the metadata (and other fastArray caches) by improving our 'hit-rate' on intercepting requests at the fast array cache #24156

This adds a much smaller boost in intercepts such that the pattern of

if (Civi::cache('metadata')->has($key)) {
  return Civi::cache('metadata')->get($key);
}

results in one lookup of the underlying cache rather than two.

Before

A call to has on a fastArray cache does not result in the value retrieved from the get request that it does being cached to the array so we wind up with two get requests when we do has followed by get - has seems to call get internally anyway - but not in a way the fastArray decorator can access

1660868589.692973 [0 127.0.0.1:44142] "GET" "crm/metadata_5_51_beta2/CRM_Core_BAO_OptionValue_OptionGroupID_2_en_US"
1660868589.693399 [0 127.0.0.1:44142] "GET" "crm/metadata_5_51_beta2/CRM_Core_BAO_OptionValue_OptionGroupID_2_en_US"

After

Using a get internally results in the value being cached & available for a second call

Technical Details

it's hard to think of when a has would be used without a subsequent get

Comments

This won't impact batch job performance except on the very first cache access - which suggests maybe a 120ms improvement on a single contact save on our infra - that's not a tonne & results may vary - but we have removed queries with far less impact & it's hard to see a downside

[civibot]

(Standard links)

• If this is your first pull-request for CiviCRM, please browse CONTRIBUTING.md for information about the development and testing processes.
• If you are reviewing this pull-request, you may wish to consult the test sites and the Review Standards (long template, short template).

[seamuslee001]

this seems ok to me merging