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 _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
