Collect Telemetry on whether the host system has SuperFetch / Prefetch disabled
Categories
(Core :: Widget: Win32, task)
Tracking
()
Tracking | Status | |
---|---|---|
firefox75 | --- | fixed |
People
(Reporter: mconley, Assigned: mconley)
References
(Blocks 1 open bug)
Details
Attachments
(2 files)
47 bytes,
text/x-phabricator-request
|
Details | Review | |
2.35 KB,
text/plain
|
chutten
:
data-review+
|
Details |
See https://en.wikipedia.org/wiki/Windows_Vista_I/O_technologies#SuperFetch
There are various articles on the web that advise users (likely to their detriment) to disable SuperFetch / Prefetch to (ironically) speed up their machines.
We have some data that suggests that disabling these OS services can have a serious impact on Firefox's start-up time. We'd like to know if there are users in this bucket, and how big that set is.
Comment 1•5 years ago
|
||
Data collections are usually implemented by the components doing the collection. A bit of a wild guess, but maybe widget:win32 is close enough to correct?
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Comment 2•5 years ago
|
||
Assignee | ||
Comment 3•5 years ago
|
||
Hey mhowell, I'm trying to figure out in this patch if Superfetch or Prefetch are enabled with the default params, and if so, stash that state in Telemetry.
Superfetch is a service that was introduced in Windows Vista, and had the name "Superfetch" in the service list. Since Windows 10 1809, this service has been called "SysMain".
I think what I want to do here is switch on the release ID of Windows to determine if we should be looking for "Superfetch" or "SysMain" in the service list. What are best practices for getting this value? Can I presume we want to get it out of the registry? If so, since it's a REG_SZ string, are there any guarantees on its length, or should we query the registry for the string length and then allocate a buffer for us to write the registry value into?
Comment 4•5 years ago
|
||
We have some nice helper functions in WindowsVersion.h that you can use to gate on individual Windows 10 releases. If that isn't enough I'd still recommend using the IsWindows10BuildOrLater
function there to compare against the build number for each release, rather than the version string; I like build numbers because they're so much easier to retrieve (via the GetVersionEx
API), and because they work across all Windows versions, not just 10. For quick reference, the build number of 1809 is 17763.
Assignee | ||
Comment 5•5 years ago
|
||
(In reply to Molly Howell (she/her) [:mhowell] from comment #4)
We have some nice helper functions in WindowsVersion.h that you can use to gate on individual Windows 10 releases. If that isn't enough I'd still recommend using the
IsWindows10BuildOrLater
function there to compare against the build number for each release, rather than the version string; I like build numbers because they're so much easier to retrieve (via theGetVersionEx
API), and because they work across all Windows versions, not just 10. For quick reference, the build number of 1809 is 17763.
Thanks, Molly! So it turns out that the service was always called SysMain, and it was only the display name that changed after 1809. But TIL that we have WindowsVersion.h, and it's got some great helpers. :)
Assignee | ||
Comment 6•5 years ago
|
||
Comment 7•5 years ago
|
||
Assignee | ||
Updated•5 years ago
|
Comment 8•5 years ago
|
||
Comment 10•5 years ago
|
||
bugherder |
Description
•