[DanielDarrenJones]

Paginating search results works the results out twice, and combining two or more wheres on them compares every result with every other.

Both are in IteratorBuilder, which the search query builder extends:

• paginate() calls getCountForPagination() and then get(), and each one fetches and filters the items again. For search that means turning every hit into an entry, term or asset twice, whatever the page size.
• Each where after the first is combined with the ones before it by intersectItems(), which asks $filteredEntries->contains($entry) for every item. That's a loose comparison of each object against each of the others. {{ search:results }} always adds a status where, and a site one on a multi-site, so it's the usual case rather than an unusual one.

paginate() now works the filtered items out once and uses them for both the total and the page. intersectItems() looks objects up by spl_object_id(); both sides are always taken from the same original items, so it's the same answer. Anything that isn't an object is compared as before.

Numbers

A local (Comb) index, a query with 1,022 hits, where('status', 'published')->where('site', 'en'), each in a fresh process:

	before	after
get()	~206 ms	~170 ms
paginate(10)	~393 ms	~165 ms

The second cost grows with the square of the number of hits, so the gap widens on bigger result sets.

Tests

Paginating asks for the search results once and gives the right total and page with two wheres (fails without the change), and a query can be added to and used again after paginating.