Problem/Motivation
Initially, this was reported because validateKeys() was slow. It's a lot of low level calls, so only small optimizations would be possible.
However, we then quickly identified that we are validating the keys for config data loaded from the storage/cache. Which is pointless, as we already know that it is validated, we only need to care about manually set/imported new configuration.
On my bigger site, with large config entities like page_manager pages, this validation took up to 30ms/10+% of a render-cached response.
Proposed resolution
Add a new optional argument to setData() to disable keys validation. Set that in initWithData(), where we can assume that it is only already validated data.
The result:

Remaining tasks
User interface changes
API changes
New optional argument, no other change.
Original report by @dawehner
If you look onto a warm page as an anonymous user, standard install, you see
that ConfigBase::validateKeys()needs around 2ms which is basically a little bit more than 1% of the request.
Maybe we can improve that.
Use the array cast trick to save maybe 500ms ... sure its not that much but its small bits which actually might matter much more if you have a big configured site
An alternative could be to not validate the keys on runtime, but just on save/import.
| Comment | File | Size | Author |
|---|---|---|---|
| #10 | config-set-data-validate-2380607-10-interdiff.txt | 815 bytes | berdir |
| #10 | config-set-data-validate-2380607-10.patch | 2.27 KB | berdir |
| #4 | setData.png | 61.41 KB | berdir |
Comments
Comment #1
dawehnerComment #2
damien tournoud commentedThe bytecode analysis is not very exciting: http://3v4l.org/U8hdK
Clearly the new version will be much slower on HHVM (which has a dedicated opcode for is_array), and I doubt it is actually faster outside of a development environment on legacy PHP (because xdebug, xhprof, uprofiler and friends tend to slow down function calls).
Comment #3
dawehnerI'm pretty sure I had xdebug disabled, but yeah uprofiler might have been problematic.
This is all quite tricky, but I wonder in general whether we really have to validate the keys on runtime.
Comment #4
berdirIt's 5% for me on an actual site, with 75% calls.
Yes, I don't think the problem is that it is slow, the problem is that we should only call it when you manually call $config->set() and not validate data that's coming from the storage?
So changing the title.
Also, it looks like we are calling setData() twice?
Config extends StorableConfigBase:
StorableConfigBase:
Is that really necessary?
The attached patch adds a $validate_keys option to setData() and sets it to FALSE in initWithData().
I don't know how much of this is overhead, but I think the screenshot below explains why this is major :)
And it doesn't matter much anymore if we call it twice or not.
Comment #5
berdirComment #6
alexpottYou're right - I think this setData() is superfluous - afaics.
Comment #7
berdirOnly one way to find out. Won't make much of a difference now, though.
Comment #8
dawehnerWe still should document this parameter
Comment #9
berdirImproved the comment a bit.
Comment #10
berdirAdded the missing (optional).
Comment #11
berdirComment #12
alexpottNice work.
Comment #13
alexpottI've reviewed all the calls to initWithData - they all should be receiving configuration that has already been validated.
Comment #14
wim leersWow, amazing find!
Comment #16
catchNice find. Committed/pushed to 8.0.x, thanks!