Problem/Motivation

https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Entity%21...
User entities don't have a langcode entity key.
When constructing a new user entity, we try to get the default langcode.
There's no entity key, so it loads all the field definitions to see if one is for langcode.
Then it doesn't find one, so sets it to LanguageInterface::LANGCODE_NOT_SPECIFIED
I only found this because I tried switching to this to fix #2479529: \Drupal\user\ContextProvider\CurrentUserContext::onBlockActiveContext() should avoid loading the anonymous user, but profiling shows it's significantly worse.
Proposed resolution
Shortcut all this for entity types that we know aren't translatable, without completely removing the ability to make them translatable again from contrib. Not sure the best approach for this.
A fix for user module would be to add a langcode entity key but force it to LANGCODE_NOT_SPECIFIED all the time, but that won't help other entities and it'd probably mean a schema change.
Remaining tasks
User interface changes
None.
API changes
Possibly a change to the User class/annotations.
| Comment | File | Size | Author |
|---|---|---|---|
| #10 | user-anonymous-langcode-2504849-10.patch | 766 bytes | berdir |
| Screen Shot 2015-06-11 at 9.59.25 PM.png | 107.79 KB | catch |
Comments
Comment #1
dawehnerWell, in case the logic is in the content entity class, people could, and we maybe should try to make that easy, override those methods to make it translatable again.
Comment #2
dawehnerComment #3
fabianx commentedComment #4
andypostThe related #2345611-70: Load user entity in Cookie AuthenticationProvider instead of using manual queries shows that we need language to access roles in authentication
suppose we need optimize access to entity values always providing langcode
Comment #5
yesct commentedComment #7
catchDiscussed with xjm, alexpott and effulgentsia and we triaged this as major due to the performance impact.
Comment #8
berdirCan we just do this?
I didn't profile this, but I verified that it did go into the first if().
Comment #9
jibranThis is not needed.
Comment #10
berdirComment #11
jibranI think we should add some tests for this and profile the patch.
Comment #12
berdirThere is no functional change here, it results in exactly the same behavior, just in a directer way, so not sure what you want to test?
Comment #13
fabianx commentedI agree and it is pretty clear this saves performance - though it would be nice to see how much.
Comment #14
alexpottI thought about requiring a unit test here. The best I could come with is:
I think this might be a bit heavy on testing implementation and not behaviour.
Comment #15
alexpottOn php 5.6 on a page with 1 anonymous comment I see very small improvements...
Comment #16
alexpottThese improvements will grow with more anonymous comments therefore I'm going to commit this to 8.3.x and set to patch to be ported for 8.2.x. I've credit everyone who did any performance profiling on the issue.
Committed 05705fc and pushed to 8.3.x. Thanks!
Comment #19
catchCherry-picked to 8.2.x