Hi Dave, > If we split recipes into 1 html page per tab, ...
I think that you are referring to the Recipe Detail page (recipe.html). That page does have four tabs (implemented as "wells"), but it is very small and localized to a single recipe, so I do not see load delays. The page I am referring to is the "All Recipes" page (recipes.html). It has no tabs. It does have a column for forward dependencies and a column for reverse dependencies per package, and that is where the load time comes from. We can certainly consider reducing the default count from 100 to 25, but I think that my proposed speed up is applicable in all cases, especially if the user decides they really want to 100 line view for their own purposes. - David > -----Original Message----- > From: Lerner, Dave > Sent: Friday, April 11, 2014 7:20 AM > To: BARROS PENA, BELEN; Reyna, David > Cc: [email protected] > Subject: RE: [review-request] V2: 6137 excessive load time for All Recipes > page > > 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:[email protected]] > > Sent: Friday, April 11, 2014 7:41 AM > > To: Reyna, David; Lerner, Dave > > Cc: [email protected] > > Subject: Re: [review-request] V2: 6137 excessive load time for All Recipes > page > > > > On 11/04/2014 01:44, "Reyna, David" <[email protected]> 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 > > -- _______________________________________________ toaster mailing list [email protected] https://lists.yoctoproject.org/listinfo/toaster
