EntityLastInstalledSchemaRepository::getLastInstalledDefinition() loads all definitions

This complicates having a global cache, because we don't know if we only partially loaded them or not. There are almost no direct calls to that, so I'm tempted to just drop the global cache to avoid storing these things twice (three times with the regular definition) in apcu. The awkward part is that we'd write all the caches every time we do, deleting one-off caches is also a bit weird.

I'm also tempted to drop the build-all approach to this, it would add a bunch of queries to cold caches, but we might save some memory?

the only direct non-updates call I found in contrib is https://www.drupal.org/project/config_track, which is weird, no idea why that uses installed definitions, it's just for config entities.

I can try to explore dropping the build all, shouldn't be complicated. I first thought hat there wouldn't be any conflicting race conditions when doing it one-by-one, but maybe during updates or so, when the change the data and then other request writes the old info, so might be better to go with immediate write for now.

The very slow setMultiple() cache writes are a bit surprising, I also see some similar one for the default bin and even config.

Dropped the build mechanism, debugging it a bit, one thing I noticed is that on a multilingual site, we first get a bunch of field storage definitions through \Drupal\content_translation\Hook\ContentTranslationHooks::entityBaseFieldInfo(), so #3616962: Do not load installed field storage definitions in ContentTranslationHandler::__construct() wouldn't help, as we really need the data, which didn't do the build all, so we loaded those and then we loaded them again when the first entity type active definition is loaded, which is in this order on umami with a drush cr

* \Drupal\media_library\MediaLibraryEditorOpener::__construct through the \Drupal\Core\Entity\EntityResolverManager route altering, which #3617141: Do not load installed field storage definitions in SqlContentEntityStorage::__construct() will actually help
* \Drupal\menu_link_content\Plugin\Deriver\MenuLinkContentDeriver::getDerivativeDefinitions

(no views build, not on a drush cr).

On the web request, the first thing then is in fact views data, through a fiber. Which builds all field definitions due to the getBundles() call.

Hm. One downside is that this will take quite a while to warm up the caches, no? every time one entry is not yet cached, it will load all, then store just that one in the cache and not the others used in that request. So if you you need 5 of them in a typical request, it will take 5 requests of load-everything, including those that already are cached until the cache is warm?

I already thought about using the BackendChain with memory cache pattern here to simplify the lookups, we could introduce that to make a difference between bulk-loading and the cache, but then we'd also add cache misses for already bulk-loaded items, we would need to make it explicit to avoid that, but we might also write back already persistently-cached items then.

If we go with this approach, we should also do the same for field storage definitions, that should remove several queries on umami cold cache.

Other than that, the one reason I'm not quite sure about this approach is that we also "install" config entity types, which we never request, because that concept actually doesn't mean anything for them. select name from key_value where collection = 'entity.definitions.installed' and name like '%entity_type' on umami gives me 33 results, only 9 of those are content entity types and are requested. that we no longer cache them is good but we still load them into memory on misses. But we could possibly look into no longer "installing" them in a separate issue. That would break modules relying on them being there, that config_track module above would go from being slower to being completely broken then.

since the build part of the cache is so fast, I think the multiple requests would need to be *very* close together with, I'd expect that a few (as in, 2-3?) milliseconds should be plenty to start hitting warm persistent caches already? It generally also happens within larger build processes, such as views data and routing on colld caches. routing already has a lock, we could add one to views data too, then it's pretty unlikely that we get stampedes on these requests.

Yes, BC like that might work, means we have to hardcode that logic directly into the service, but for BC that seems fine. Unsure what the logic would be. not-config-entity or only-content-entity? nothing else exists in core, but it might in contrib/custom code.

> I really meant vs HEAD though where it's more like 80ms.

True. Both options are significantly better than HEAD I think, should be minor differences.

I think my long term plan is to find ways to stop building the field map and all bundle field definitions completely, so I'd take a few extra queries now with the possibility to not load that data at all later. But at the same time, it might not be "a few" especially with field storage definitions and then if we expect to load most/all of them anyway, we gain various extra queries with little to no memory wins. But then there's the slow cache build-up, I don't really know.

Looking at my site, I have 147 items in that collection, 110 of which are entity_type definitions. In regards to size, it's almost 1MB for field storage definitions in string length and .36MB for entity type definitions, so field storage definitions make up the bulk anyway.

I think if we add the bulk load to field storage definition load as well then we have a net positive on query count as these happen first on multilingual sites, and then I think we could explore if we want to take the hit on extra cache get misses on cold cache so we know which ones aren't cached yet and write them back on the cache from the bulk-loaded list. I think that would also increase the chances of fewer requests needing to bulk load as they start to hit the if they're slightly behind the leading one, plus there's the lock thing anyway. Then we can revisit the bulk load if/when we no longer have a field map

I'll also file a follow-up to consider a lock on views data and one to get rid of the config entities.

The separate all list is actually needed, what happened before is that there were some cache hits, then miss, which fell back to loadAll, but that had already partially loaded data and returned early.

This has higher cache get/set counts on cold caches, but total queries don't go up (I kind of expected them to, but I guess I tested cache clear on drush and on web requests, first active entity type definition is still the first thing to be called) and it should reach a stable cache quicker.

Didn't update all performance test yet, can't really be bothered anymore to do manual query list updates after working with #3618432: Performance tests: Move expected metrics and queries to files, for better diffs and automated updates I think I'll just focus on pushing that through.

Rebased and updated all performance tests now.

bot was confused about the multiple open branches.

Rebased again.

Rebaased.