← Back to team overview

launchpad-dev team mailing list archive

performance tuesday - BugTask:+index

 

I had a pretty fun day today. I haven't got anything earthshaking to
share, but I should have removed a large cost factor from
BugTask:+index - sufficient to let bug 1 render its partial view
again. Handling all bug messages requires some pagination or (better)
ajax love: but this is within striking distance now.

The enabler for this is the new BugMessage.index column we added late
last year, and which we populated last week via the garbo.hourly. This
permits the database to be told 'give me the 1st 40' messages and
likewise get the last 40. Previously we could do the first 40, but not
as easily the last 40 - at least with the indices we had.

In terms of changes, we have two very similar things -
bug.indexed_messages and bug.getMessageForView (was getMessageChunks),
which probably could be combined, if we actually have BugMessage used
rather than the browser only 'BugComment' class, which seems entirely
redundant.

Most of what I've been doing is just rearranging things so that:
 - we expose to the db layer the data window we need
 - we don't assume that we've examined every single bug message in the UI.

For instance, rather than counting '4 total visible comments', we say
'5 total comments', and the hidden one will always just be visible to
admins. We may get some bugs about this, and it is solvable - but we
can and should fix the data model to permit doing this from the db
layer rather than deserialising /everything/.

The query count actually goes up slightly with my branch, but the new
queries are 10 times faster, so its a win overall on large bugs, and
inconsequential on small bugs.

I will be testing this and putting it up for review tomorrow.

-Rob



Follow ups