[Toaster] [review-request] V2: 6137 excessive load time for All Recipes page

[Lerner, Dave]

If we split recipes into 1 html page per tab, then the apparent delays will be split into a few seconds per tab switch, and probably less since the tab-specific queries can be optimized further using either the forward or reverse joins on package and package_dependency (for example for the package tab).

However, the greatest side effect of that change, 1 html page per tab, is simplicity in using other 'included' pages that define sorting and search bars without adding a lot of logic that tries to send the active #anchor from the client to the server in some encoded form, and then re-encode it back through our view functions to the client.

Also I feel strongly that the simplest solution is to switch to a default of 25 rows for this view.  Here's why: we have column sorting, and rows-per-page widgets, so I don't feel that the primary workflow will be perusing long lists, but rather filtering to find what you want, either by entering strings, sorting alphabetically, or sorting on size.  

For that matter (an aside) if long list browsing must be supported, then there isn't a reason  to constrain that list to 100 rows - it should be a pull-down or input field with a max value on the order of 10^3 rows.

Dave
> -----Original Message-----
> From: Barros Pena, Belen [mailto:belen.barros.pena at intel.com]
> Sent: Friday, April 11, 2014 7:41 AM
> To: Reyna, David; Lerner, Dave
> Cc: toaster at yoctoproject.org
> Subject: Re: [review-request] V2: 6137 excessive load time for All Recipes page
> 
> On 11/04/2014 01:44, "Reyna, David" <david.reyna at windriver.com> wrote:
> 
> >Here are the timing results on my slow host for the rendering time:
> >
> >  (a) Original: 13 seconds
> >  (b) V1      :  7 seconds
> >  (c) V2      :  4 seconds
> 
> This is obviously a huge improvement. What bothers me is that the Recipes
> page still seems to be performing much worse than all other pages. Should
> we be trying to fix the root cause of the problem, ie. the "100*(2+2)
> foreign key lookups and filters/count"?
> 
> Thanks!
> 
> Belén
>