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.
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.
Discussion, patch, etc.
None.
None.
None.
Maybe...
| Comment | File | Size | Author |
|---|---|---|---|
| #9 | 2018-12-03 11-19-09.png | 21.45 KB | e0ipso |
| #3 | 3016725--do-not-use-cache-static--3.patch | 5.54 KB | e0ipso |
Comments
Comment #2
e0ipsoComment #3
e0ipsoActually, we should avoid any cache service at all and go back to basics. This patch uses a protected property for this matter.
Comment #4
e0ipsoAlso, JSON:API will probably stop using the cache service too.
Comment #6
e0ipsoComment #8
ndobromirov commentedThis can be further seeded up by:
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().
Comment #9
e0ipsoFor the untrained eye:
What @ndobromirov is to avoid the
array_key_existscall when possible because it's considered a slow method (although it's still implemented in C).This will have the effect of prepending an
issetcall 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?