Closed Bug 727864 Opened 12 years ago Closed 12 years ago

Enable DLL preloading when MozillaMaintenance service disabled prefetch

Categories

(Core :: Widget: Win32, defect)

x86_64
Windows 7
defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla15

People

(Reporter: bbondy, Assigned: bbondy)

References

Details

(Whiteboard: [qa?])

Attachments

(1 file, 3 obsolete files)

We currently only do DLL preloading when we think that the Windows prefetch isn't used.  We should also do DLL preloading when the maintenance service has performed a successful clear prefetch operation.
Attached patch Patch v1. (obsolete) — Splinter Review
Attachment #597866 - Flags: review?(jmathies)
Alfred Kayser 2012-02-16 23:59:42 PST

I would move the LOG statement of the failing WritePrefetchClearedReg function inside that function, just as the other LOG statement is also there.
+  if (retCode != ERROR_SUCCESS) {
+    LOG(("Could not open key. (%d)\n", retCode));
+  }
And, add a 'return false' here after the LOG.
Attached patch Patch v2. (obsolete) — Splinter Review
Implemented review comments and rebased to m-c tip.
Attachment #597866 - Attachment is obsolete: true
Attachment #598233 - Flags: review?(jmathies)
Attachment #597866 - Flags: review?(jmathies)
Comment on attachment 598233 [details] [diff] [review]
Patch v2.

Review of attachment 598233 [details] [diff] [review]:
-----------------------------------------------------------------

::: browser/app/nsBrowserApp.cpp
@@ +251,5 @@
>    // in the program. Luckily 1 coincides with when prefetch is
>    // enabled. If Windows prefetch didn't happen we can do our own
>    // faster dll preloading.
> +  // The MozillaMaintenance service issues a command to disable the
> +  // pretch by replacing all found .pf files with 0 byte read only

nit - 'pretch'

::: toolkit/components/maintenanceservice/prefetch.cpp
@@ +54,5 @@
> +  LONG retCode = RegOpenKeyExW(HKEY_LOCAL_MACHINE, 
> +                               BASE_SERVICE_REG_KEY, 0,
> +                               KEY_WRITE | KEY_WOW64_64KEY, &baseKeyRaw);
> +  if (retCode != ERROR_SUCCESS) {
> +    LOG(("Could not open key. (%d)\n", retCode));

does this LOG macro do file name / line number logging? If not you might want to make that msg more specific.
Attachment #598233 - Flags: review?(jmathies) → review+
Attached patch Patch v3. (obsolete) — Splinter Review
Implemented nits, carrying forward r+.
Attachment #598233 - Attachment is obsolete: true
Attachment #599602 - Flags: superreview?(robert.bugzilla)
Attachment #599602 - Flags: review+
Comment on attachment 599602 [details] [diff] [review]
Patch v3.

Actually I don't think this one needs a super-review so clearing that flag.
Attachment #599602 - Flags: superreview?(robert.bugzilla)
Attached patch Patch v4Splinter Review
Rebased to tip
Attachment #599602 - Attachment is obsolete: true
Attachment #623704 - Flags: review+
No longer depends on: 692255
Depends on: 692255
Depends on: 758206
http://hg.mozilla.org/mozilla-central/rev/21ae85ff4286
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: mozilla13 → mozilla15
Whiteboard: [qa+]
Is there anything to verify here from an end-user perspective?
Whiteboard: [qa+] → [qa?]
No this was verified by seeing telemetry data.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: