[meta] Investigate performance regression in Drupal 8.9.x and 9.x and 10.x

Do we have any updated performance tests that also show number from our current 10.x?

It was mentioned by @alexpott in comment #14
#3131589-14: Investigate performance regression in Drupal 8.9.x and 9.x and 10.x →
that the following issue began the spike in queries and reduced performance
🐛 Shortcut hook_toolbar implementation makes all pages uncacheable Fixed

was there any action done to mitigate this or resolve it?

@joseph.olstad no if you read the comments following #14, while it was possible to find extra database queries due to extra cache tags/cache gets, those were an expected result of the change that was made (which should have other positive side effects, just not in that specific scenario), and they don't account for the timing regression, which no-one can reproduce outside of the original test case where it was seen. #2935804: Add cache context exclusion list to RenderCache::set() → is the issue for fixing those extra cache gets/sets by allowing the render cache to skip certain items without them being uncacheable.

📌 Return early in AssetResolver::getJsAssets() and AssetResolver::getCssAssets() when there are no libraries to load Needs review fixes part of the issue discussed in #28 - optimizes ::getJsAssets() to avoid running the same logic when the same arguments are passed in. This doesn't only save some js settings alter logic but also removes some cache gets for the same thing too.

📌 Return early in AssetResolver::getJsAssets() and AssetResolver::getCssAssets() when there are no libraries to load Needs review is in!

I realised while working on it that we can improve things a bit more there, so opened 📌 Optimize AssetResolver caching Active

✨ Introduce a list of "common cache tags" to reduce lookup query amount Active is also open now to try to reduce queries from cache tag lookups further.

I think with these, we can probably close this issue since everything has either been documented in separate issues now, or turned out not to be reproducible?

Changing status to reflect the above.

I think with these, we can probably close this issue since everything has either been documented in separate issues now, or turned out not to be reproducible?

Yep I agree.

Automatically closed - issue fixed for 2 weeks with no activity.