Problem/Motivation

As found in #3014232: [regression] ResourceTypeRepository is significantly slower in JSON:API 2, becomes noticeable when handling hundreds of interlinked resources cache.static is a problematic beast. We are still using it in a container alter scenario to match behaviors comming from jsonapi 2.x.

Proposed resolution

Introduce a new private service in the way it was added for jsonapi in jsonapi_extras. Use that instead of depending on the one used from the other module, so we can drop one hidden dependency - the protected property cacheStatic.

Remaining tasks

Discussion, patch, etc.

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

Maybe...

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

ndobromirov created an issue. See original summary.

e0ipso’s picture

Version: 8.x-1.x-dev » 8.x-2.x-dev
e0ipso’s picture

Status: Active » Needs review
FileSize
5.54 KB

Actually, we should avoid any cache service at all and go back to basics. This patch uses a protected property for this matter.

e0ipso’s picture

Also, JSON:API will probably stop using the cache service too.

  • e0ipso committed b4ac77c on 8.x-2.x
    Issue #3016725 by e0ipso: Do not use cache.static
    
e0ipso’s picture

Status: Needs review » Fixed

  • e0ipso committed c6f1135 on 8.x-3.x
    Issue #3016725 by e0ipso: Do not use cache.static
    
ndobromirov’s picture

This can be further seeded up by:

  1. Simplify the cache ID generation. As we are storing in an instance property we will not need the resource ID as part of the key.
  2. Add an isset() || array_key_exists() so we can spare the function call if we have a valid cache and not a NULL value in there. This is a hot method, so even micro-optimizations will show up.

I will pass a patch once I am testing performance in #3017262: Further speed-ups in ConfigurableResourceType::getResourceFieldConfiguration().

e0ipso’s picture

FileSize
21.45 KB

For the untrained eye:

What @ndobromirov is to avoid the array_key_exists call when possible because it's considered a slow method (although it's still implemented in C).

This will have the effect of prepending an isset call so we may be doing extra work. This optimization makes sense when the majority of the resource are not disabled. I don't think we can ensure that's the case, right?

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.