Group permission checking peformance issue after updates

was called 18 times on a page refresh of /node/add/blog before the update and now after the update it is called 7058 times

Holy crap

Any idea what could be causing such an extreme difference?
Could this be a caching issue or issue with the permission calculator?

Not unless this can be reproduced on a clean install. I have no clue what custom code and/or patches you have running, so either please run xhprof, Blackfire or whatever performance testing tool you're confident using or see if you can reproduce this on a clean install.

Erring on the side of Major right now as if this is the case for all Group installs, something is really broken.

Thank you, I understand. There is a lot of custom code so I would say this is site specifi9c issue, and I have checked on a similar site but was not able to reproduce it there. I will roll back the group update and see if there is any change.

Profiling shows that the access checking is running on menu items (structured in a large menu) which is loading on the create node pages and group entity access is called in that call stack, so I am trying to understand if these group entity access checks were cached before and at which layer they were cached.

Okay, please keep me posted.

I found that the changes from https://www.drupal.org/project/drupal/issues/2463753 🐛 [regression] Do not bypass route access with 'link to any page' permissions for menu links Fixed causes the performance issue.

I can see that when menuLinkCheckAccess is called it is not returning `$access_result->cachePerPermissions();` any more so the cacheContexts and cacheTags has changed from:

Drupal\Core\Access\AccessResultAllowed 
  #cacheContexts: array:1 [▼
    0 => "user.permissions"
  ]
  #cacheTags: []
  #cacheMaxAge: -1
}

to this:

 Drupal\Core\Access\AccessResultAllowed {
  #cacheContexts: array:3 [▼
    0 => "url.query_args:auHash"
    1 => "user.permissions"
    2 => "languages:language_interface"
  ]
  #cacheTags: array:25 [▼
    0 => "group_content_list:plugin:group_node:blog"
    1 => "group_content_list:plugin:group_node:<content_type_2>"
    3 => "group_content_list:plugin:group_node:<content_type_3>"
    ...
  ]

There are 23 cacheTag items coming from `group_content_list:plugin:group_node:.

Not sure if that is expected but seems to cause in issue in my case.