The function backup_migrate_help initializes the array with help strings before checking whether it is needed. This leads to a minor performance hit on practically each page request as the translate function is called multiple times (database lookup per call).
Possible solutions:
- use a switch statement
- bail out early if $section does not start with BACKUP_MIGRATE_MENU_PATH or is not equal to admin/help#backup_migrate (this solution is, looking at the logic regarding admin/help#backup_migrate, probably the simpler one but will still call too many t()'s on your own pages.
| Comment | File | Size | Author |
|---|---|---|---|
| #8 | backup_migrate-n1042672-7.patch | 11.75 KB | brankoc |
| #2 | 1042672.patch | 10.08 KB | fietserwin |
| #1 | 1042672.patch | 10.08 KB | fietserwin |
Comments
Comment #1
fietserwinPlease find attached a patch that solves the problem as well as serves advanced help.
Comment #2
fietserwinOops, typo in patch. Please use this one.
Comment #3
fietserwinComment #4
fietserwinSimple patch, hardly anybody will notice this problem, so few chances to get reviewed by other people. So, I push this one to RTBC.
Comment #5
couturier commentedThe 7.x-2.x branch will be deprecated soon. See this issue: Verify 7.x-2.x -to- 7.x-3.x upgrade path, mark 7.x-2.x as unsupported.
If this issue still exists in the 7.x-3.x branch, the patch will need to be rewritten.
Comment #6
damienmckennaComment #8
brankoc commentedReroll against 7.x-3.x.
I am not sure how useful this is, as the increased page load time of the initial situation seems minimal, but I guess it is never a bad idea to be a good citizen.
1) I manually applied #2.
2) Fixed some minor (but perhaps not all) coding standards issues.
3) Added in the access checks that had been added to backup_migrate_help() since patch #2 was released.
Comment #10
damienmckennaCommitted. Thanks everyone.