launchpad-dev team mailing list archive

[Robert Collins <robert.collins@xxxxxxxxxxxxx>]

On Wed, Sep 22, 2010 at 1:16 AM, Guilherme Salgado
<salgado@xxxxxxxxxxxxx> 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