SearchApiTagCache::getRowId is very expensive

Your suggested change makes sense and looks good to me. I only have one nitpick, but that can be fixed on commit.

+++ b/src/Plugin/views/cache/SearchApiTagCache.php
@@ -81,4 +82,32 @@ class SearchApiTagCache extends Tag {
+    $row_data = array_diff_key((array) $row, array_flip(['_item', '_object', '_relationship_objects', $row->search_api_datasource . '/_object'])) + $this->getRowCacheTags($row);

This line is getting pretty long. Maybe extract the array_flip(...) bit into a variable to improve readability?

Thanks a lot for the patch, good suggestion!
However, it seems excluding $row->search_api_datasource . '/_object' specifically isn’t enough, as other such properties can contain entities as well (e.g., in my case, $row->{'entity:node/type:_object'}). So probably we need a more advanced solution here, going throw the whole (array) $row array and unsetting all search items, entities and (probably also?) entity wrappers. Or maybe we can replace them with a unique string, like entity::node::123, just to be on the safe side? If we’re already adding a helper method to go through all properties (recursively, I guess), this shouldn‘t be much extra work. (I’m not at all certain our cache tags are adequate, that’s the problem here, so better be on the safe side regarding the properties, I’d say.)

Hm, OK, I guess that could work. Not sure, though, don’t understand caching (especially for Views) well enough. Would be great to have others confirm this makes sense and works for them (or looks to them like it should work).

In any case, though, $row->_relationship_objects already contains $row->_object, so we can simplify a bit. (Otherwise, we’d have to verify that this is an entity, too.)

In any case, this change looks like it would break things for indexes that contain non-entities – but since that’s a rather minor use case, and the problems should not be large (just potentially showing stale data until item is re-indexed), I think we can live with that compared to the large performance gain for the main use case.

Also, is there a simple way to get this covered by tests, do you think?

Alright, that’s probably not worth it.
So, let’s just commit this.
Thanks again, everyone!