Problem/Motivation
We've added a static cache layer in #3007091: Performance issue in ConfigurableResourceType, but we are misusing it a bit :)...
Internally the static cache implementations are checking:
// ...
if (!isset($cache->data)) {
return FALSE;
}
// ...
So when we save NULL this is essentially cache misses on the next cache get for the item.
Before:

After:

Proposed resolution
My proposal is to use FALSE as a tombstone in the cache and have a single ternary operation to fix the return value to a NULL as the interface is promising.
Patch will follow soon.
Remaining tasks
Patch discussion commit.
User interface changes
None.
API changes
None.
Data model changes
None.
Release notes snippet
None.
| Comment | File | Size | Author |
|---|---|---|---|
| #9 | Workspace 1_239.png | 134.25 KB | ndobromirov |
| #9 | Workspace 1_238.png | 146.49 KB | ndobromirov |
| #9 | 3017262-9.patch | 1.2 KB | ndobromirov |
| Workspace 1_236.png | 206.79 KB | ndobromirov | |
| Workspace 1_235.png | 193.99 KB | ndobromirov |
Comments
Comment #2
ndobromirov commentedComment #3
ndobromirov commentedHere is the promised patch...
Comment #4
ndobromirov commentedComment #5
ndobromirov commentedComment #6
e0ipsoCan you please profile the latest version of the -dev branch. It seems that there is a conflict with some recent changes.
#3016725: Do not use cache.static
Comment #7
e0ipsoComment #8
ndobromirov commentedWill do some time today.
Comment #9
ndobromirov commentedHere is the profile with the latest dev:

Here is the one with the micro-optimizations proposed in the other issue and the attached patch:

Comment #12
e0ipsoThanks! This was fixed.
Comment #13
ndobromirov commentedAwesome!
if I check the first benchmarks 474ms to the last committed ones 22ms - 21x improvement! :D