On Wed, Sep 22, 2010 at 1:16 AM, Guilherme Salgado <[email protected]> wrote: > Hi Robert, > > While reading your report it struck me that although we now have a test > asserting the number of DB queries issued by that page (you added one, I > guess?), the code that might trigger these queries is still scattered > all around, making it tedious (as you described) for someone to map > issued queries to the code issuing them. IOW, we're less likely to see > this page regressing and issuing lots more queries, but it's still a > significant amount of work just to find the bits that still need to be > optimized. > > Wouldn't it be nice if all the code doing DB access was in a single > place so someone could start by guessing which piece of code was issuing > certain queries, drop into the debugger just to assert that and then > move on to optimize it? > > We should be able to do that by having just a single view method > (obviously calling other helper methods) which fetches and prepares all > the data to be used when rendering the view, and then a test asserting > that all the queries issued by the page are actually issued within that > method. If we want we can go a step further and somehow mark these > views so that the transaction is automatically doomed (or something like > that) after the fetch/prepare method is called. > > What do you think?
I think that would be lovely. there are some things that will make it tricky (e.g. BugTask:+index actually uses 2, or maybe more, view objects : but we care about performance across the /page/ not the view). Well worth spending time on IMO. I've been heading this way in the patches I do - building single functions that obtain just the right amount of data, sliced or not, with various attributes calculated (or not) - but its very hand craft, rather than introspected and code-generated. Another thing that would be nice is to pipeline stuff - to turn DB access /off/ during the render stage, so that we don't have any unpleasant performance suprises (and we could even, in principle, move to a multicore model there, if we weren't using python :P) This is also similar to the threads about separating persistence from business logic, which may be a supporting change. -Rob _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
