Merge lp:~jtv/launchpad/bug-994650-cache-potmsgsets into lp:launchpad
| Status: | Merged | ||||
|---|---|---|---|---|---|
| Approved by: | Jeroen T. Vermeulen on 2012-05-11 | ||||
| Approved revision: | no longer in the source branch. | ||||
| Merged at revision: | 15299 | ||||
| Proposed branch: | lp:~jtv/launchpad/bug-994650-cache-potmsgsets | ||||
| Merge into: | lp:launchpad | ||||
| Prerequisite: | lp:~jtv/launchpad/bug-994650-scrub-in-batches | ||||
| Diff against target: |
637 lines (+599/-0) 4 files modified
database/schema/security.cfg (+1/-0) lib/lp/scripts/garbo.py (+4/-0) lib/lp/translations/scripts/scrub_pofiletranslator.py (+281/-0) lib/lp/translations/scripts/tests/test_scrub_pofiletranslator.py (+313/-0) |
||||
| To merge this branch: | bzr merge lp:~jtv/launchpad/bug-994650-cache-potmsgsets | ||||
| Related bugs: |
|
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| j.c.sackett (community) | 2012-05-09 | Approve on 2012-05-10 | |
|
Review via email:
|
|||
Commit Message
Cache POTMsgSets per template in POFileTranslator scrubber.
Description of the Change
This is one of two further optimizations to the POFileTranslator scrubber as mentioned in this MP: https:/
It's a very simple change. For each POFile that the scrubbing loop processes, it needs to know the ids of all POTMsgSets that participate in the template. But that set may well be the same for two or more POFiles in the batch, so this caches them.
There is no caching across batches, because one batch is handled in one transaction, and a concurrent template import could update the set of POTMsgSets participating in a template between transactions.
To test, use my combined branch which also includes schema changes: lp:~jtv/launchpad/combined-async-pofiletranslator
Run this test:
{{{
./bin/test -vvc lp.translations
}}}
No lint.
Jeroen
| Francis J. Lacoste (flacoste) wrote : | # |
On 12-05-10 11:13 AM, j.c.sackett wrote:
> It doesn't look like this total arc of work reduces LoC, but I'm not familiar enough with everything you've been doing in the LP code base lately to know if you've got credit or not. I don't want to block a fix for a critical, so I'll just leave this as a reminder to please try and reduce the overall LoC going forward if you haven't already.
Jeroen gets a waiver because even though this doesn't reduce LoC, it
does reduce maintenance burden a lot, as it will allow us to open new
translation series without the multi-day fuss that is happening right
now :-)
--
Francis J. Lacoste
<email address hidden>
| Jeroen T. Vermeulen (jtv) wrote : | # |
Thanks for the review! I was wondering when the LoC thing would come up. :) In defense of Francis' note, not entirely without self-interest, I'm also obviating considerable command-lining and human-scripting (“disable X, click Y”) for every Ubuntu cycle.
> Looks good. One suggestion:
>
> Instead of
>
> 13 + if template_id not in cached_potmsgsets:
> 14 + cached_
> 15 + potmsgset_ids = cached_
>
> I think you can just do
>
> 13 + potmsgset_ids = cached_
> get_potmsgset_
That would evaluate get_potmsgset_
Does make me wonder if dict.setdefault shouldn't accept a callable plus arguments so that it can evaluate lazily.
Jeroen

Jeroen--
Looks good. One suggestion:
Instead of
13 + if template_id not in cached_potmsgsets: potmsgsets[ template_ id] = get_potmsgset_ ids(template_ id) potmsgsets[ template_ id]
14 + cached_
15 + potmsgset_ids = cached_
I think you can just do
13 + potmsgset_ids = cached_ potmsgsets. setdefault( template_ id, get_potmsgset_ ids(template_ id))
dict.setdefault returns the value if the key exists, otherwise it function like dict.get(), returning the second parameter, but *also* setting it for the supplied key.
It's really just an LoC reduction, so not a major improvement, but it's a bit cleaner than the if clause set up. I'll leave it to you whether to make that change or not. I'll leave it to you whether or not you want to implement the change.
It doesn't look like this total arc of work reduces LoC, but I'm not familiar enough with everything you've been doing in the LP code base lately to know if you've got credit or not. I don't want to block a fix for a critical, so I'll just leave this as a reminder to please try and reduce the overall LoC going forward if you haven't already.
Thanks!