Hi Alex, I have redone my commit as per your comments: dreyna/recipes_loadtime_6137
Here is the new query command: queryset_dependency=Recipe_Dependency.objects.filter(recipe__layer_version__build_id = build_id) I was able to find a relation to the “build_id“ for any given recipe via its “layer_version” member, and I am using that to filter the queryset. - David From: Damian, Alexandru [mailto:[email protected]] Sent: Thursday, May 08, 2014 5:54 AM To: BARROS PENA, BELEN Cc: Reyna, David; Lerner, Dave; [email protected] Subject: Re: [Toaster] [review-request] V2: 6137 excessive load time for All Recipes page I replied to the other 6137 with a refactor request at some points in code - - filtering Recipe_Dependency so we don't load the whole table in memory; this is not scalable; we need to load Recipe_dependency only for recipes currently displayed in page - whitespace in views.py Thank you, Alex On Mon, Apr 14, 2014 at 12:35 PM, Barros Pena, Belen <[email protected]<mailto:[email protected]>> wrote: On 11/04/2014 19:57, "Reyna, David" <[email protected]<mailto:[email protected]>> wrote: >Yeow! All of 1 second render time on my slow host! > > 1397242146.23:RECIPES > 1397242147.32 delta: 1.09702301025: RECIPES > >I have updated my commit with your change: dreyna/recipes_loadtime_61 Very impressive :) > >- David > >From: Damian, Alexandru >[mailto:[email protected]<mailto:[email protected]>] > >Sent: Friday, April 11, 2014 11:05 AM >To: Reyna, David >Cc: BARROS PENA, BELEN; Lerner, Dave; >[email protected]<mailto:[email protected]> >Subject: Re: [Toaster] [review-request] V2: 6137 excessive load time for >All Recipes page > > > >Hello, > > > >I have a small modification to David's patch that improves the loading >time about 5-fold compared to his latest version, from 5 seconds to less >than 1 second on my laptop. > > > >The trick used is to bring the whole list of dependencies for the entire >recipe list in a single call, and do the match manually, instead of >getting a call per recipe. > > > >This approach allows the code to perform constant lookup times >independent of number of rows. > > > >Since I can't push to contrib on my laptop (something funky about keys), >I'm attaching the patch for review. > > > >Please let me know how it goes. > > > >Cheers, > >Alex > > > >On Fri, Apr 11, 2014 at 5:26 PM, Reyna, David ><[email protected]<mailto:[email protected]>> >wrote: >Hi Belén, > >> 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"? > >If we stay with the current design of the page, then I think the solution >is along the lines: > > 1. Add two fields to the Recipe class to hold the respective forward >and reverse counts to support instant lookup. These values are fixed when >the build completes so they can be consider constant for our purposes, >plus they would add very little overhead > to the database (if you can get this proposal past Alex). An alternate >implementation to keep the database pristine is to add the ability to >cache information like this in some runtime table, so that the >calculation time is only spent once. > > 2. Add a dynamic lookup of a given forward or reverse dependency list >when one of those buttons are clicked. In this manner we only spend the >list computation time when explicitly asked, not for every recipe whether >they want it or not. > >- David > >> -----Original Message----- >> From: Barros Pena, Belen >> [mailto:[email protected]<mailto:[email protected]>] > >> Sent: Friday, April 11, 2014 5:41 AM >> To: Reyna, David; Lerner, Dave >> Cc: [email protected]<mailto:[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]<mailto:[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]<mailto:[email protected]> >https://lists.yoctoproject.org/listinfo/toaster > > > > > > > > >-- >Alex Damian >Yocto Project > >SSG / OTC > > > > > -- Alex Damian Yocto Project SSG / OTC
-- _______________________________________________ toaster mailing list [email protected] https://lists.yoctoproject.org/listinfo/toaster
