TL;DR; Change Content Search SPI Handler to only return ContentInfo to avoid several extra queries and loading of all translations on search. Instead Search Service will hit the SPI Persistence cache to load the full object which will be faster.

Original description:
Having implemented several eZ 5 projects using the new stack only, mainly using 5.2 and 2014.01 versions, I have seen a considerable performance degradation of SearchService::findContent with increasing number of content objects and languages. Even simple things as fetching a subtree for a meta navigation became intolerably slow .

When investigating (https://github.com/ezsystems/ezpublish-kernel/blob/master/eZ/Publish/Core/Persistence/Legacy/Content/Search/Handler.php#L95) I found out that in order to retrieve the full content objects, a huge PHP array is created based on the SQL table resulting from different joins. To give you an impression of the size of this array: for a search resulting in 24 hits, this array had 44,880 rows with 39 elements each, with highly redundant data.

This is obviously slow and scales badly: A single search returning a subtree with 70 objects took twice as long as searching four locations individually for the same objects.