searchTasks much slower than reading bug collections

Which collections in particular, and what searchTask parameters?

The collections backend onto searchTasks internally, so this is in principle impossible, unless you are comparing apples and oranges.

Bugtasks. There is a complete reproduction in the linked branch. If it can no longer be reproduced, great, close it.

Lots of bugs are in principle impossible, 'and yet it moves'.

The diff that caused performance to get worse is attached.

I will try to make a short selfcontained example.

What would be ideal is two urls that should contain the same bug collection but that take different times to render.

I have an attempted reproduction in lp:~mbp/+junk/repro-742217 but it is no longer slower. Which is good ,I guess, though surprising.

However, using my kanban branch still finds that doing two separate queries is slower (1:57 vs 1:47 for ~mbp). So I guess the attempted reproduction script is not accurate.

My kanban changes, because of bug 742250, were not fetching exactly the same set of bugs before and after that change, so it's just possible that accounts for some of the difference, but it would be surprising if it accounted for the 30% difference between the two approaches.

Generating jelmer's kanban is 634s with the more selective queries, and 668s bringing back every assigned bug and filtering on the client (5% slower). I would have expected the former would be much faster, but I guess the overall time is so dominated by tracing the linked objects that bringing back a few less bugs in the top-level query barely matters.

I think there was an effect in February, but some other change in Launchpad has made it go away. At the moment the difference between the two approaches is lost in the noise of round trips.