Merge lp:~jtv/launchpad/bug-458049 into lp:launchpad
Proposed by
Jeroen T. Vermeulen
Status: | Merged |
---|---|
Approved by: | Jeroen T. Vermeulen |
Approved revision: | no longer in the source branch. |
Merged at revision: | not available |
Proposed branch: | lp:~jtv/launchpad/bug-458049 |
Merge into: | lp:launchpad |
Diff against target: |
210 lines 4 files modified
lib/lp/translations/interfaces/potemplate.py (+7/-3) lib/lp/translations/model/potemplate.py (+7/-4) lib/lp/translations/scripts/message_sharing_migration.py (+2/-2) lib/lp/translations/scripts/tests/test_message_sharing_migration.py (+86/-2) |
To merge this branch: | bzr merge lp:~jtv/launchpad/bug-458049 |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Paul Hummer (community) | Approve | ||
Review via email: mp+13779@code.launchpad.net |
Commit message
Make sure that message-sharing migration does not pull in msgids from the database.
To post a comment you must log in.
= Bug 458049 =
Memory usage is the bane of the message-sharing migration script. In a previous fix I stopped it from retrieving POMsgID objects, since only their object ids were needed for comparison. But as it turns out, the msgids were still being loaded from the database because of an implicit prejoin in POTemplate. getPOTMsgSets.
So I'm making that prejoin optional. It's still the default behaviour, but the script disables it.
This may conceivably make the counting of potmsgsets in a template slightly faster as well, as it has no need for the additional left joins. The database backend may know that too, but why put it to the trouble?
A new test tries to ensure that migration really does not suck any POMsgID objects into memory: nPerformance
{{{
./bin/test -vv -t SharingMigratio
}}}
For Q/A, try running this script:
https:/ /pastebin. canonical. com/23602/
*If* this change really helps, that test *may* not bring the staging server to its knees by consuming over 2.5 GB of address space.
Jeroen