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...
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 CreditAttribution: ndobromirov at FFW 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_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?