> DistroArchSeries.architecturetag = %s ORDER BY DistroArchSeries.id +
> + Consolidating those into just-query-it-once would save 2.5 seconds
> + straight up.
> +
> + Its also possible that the view is preparing stuff needed for GET on
> + POST, which would be wasteful.
It's not, it redirects after a POST.
> + The big killer however is ~ 600 individual bug lookups, which I am
> + guessing is being driven by notifications or something : if so we'll
> + want to restructure the events being raised.
Correct - uploads that close bugs. All of that closure/notification code is
in the lp.bugs tree.
This page is *horrendously* difficult to optimise. I've been chipping away at
it for 3 years now. The problem is that it pulls data from all over the place
and the data it needs depends on other data which depends on other data. I
know of one definite place that can be attacked that has not been optimised
yet.
> DistroArchSerie s.architecturet ag = %s ORDER BY DistroArchSeries.id +
> + Consolidating those into just-query-it-once would save 2.5 seconds
> + straight up.
> +
> + Its also possible that the view is preparing stuff needed for GET on
> + POST, which would be wasteful.
It's not, it redirects after a POST.
> + The big killer however is ~ 600 individual bug lookups, which I am
> + guessing is being driven by notifications or something : if so we'll
> + want to restructure the events being raised.
Correct - uploads that close bugs. All of that closure/ notification code is
in the lp.bugs tree.
This page is *horrendously* difficult to optimise. I've been chipping away at
it for 3 years now. The problem is that it pulls data from all over the place
and the data it needs depends on other data which depends on other data. I
know of one definite place that can be attacked that has not been optimised
yet.