Speed up Windows boot for fun and profit
If we reboot 15 times a year, then every “tuning” of the download process takes longer than will win at reboots for the lifetime of the system. However, sporting interest rises, moreover, that people are interested in the process of optimizing performance. A boot was the most obvious candidate as an example of how the process should look like itself. We will boot at the speed 5400 of hard drive in the “working” system: in addition to a vendor crapware, there is still a lot of every types of visual studio, antivirus, skype ...
There are not specific and generally applicable tips regarding the work optimization of operating system (OS), just as there is not specific advice for accelerating the work of any randomly taken program. In the same way as in the individual programs, the work of the entire system can be seriously delayed due to one or two seemingly insignificant places. To find such “bottlenecks” in the programs there are tools called profilers. There is nothing strange that to find “bottlenecks” in the operating system, we will also use the profiler (no quotes - it is really a profiler with both sampled and instrumented). Recently, the WPA Tools extend in the Windows SDK. Putting a full SDK completely optional. We can install only «Windows Performance Toolkit»:
Traces will gather with xbootmgr. Out of magic is used only autologger including capturing ETW traces beginning with the winload. Getting help we can enter xbootmgr-help. For those who wish can enter xperf-providers (or logman providers). Each provider has a few keywords, each keyword turns on / off several types of events.
Caution, this command automatically reboots a computer
After rebooting in the directory which this command was executed will remain a file “boot_BASE + CSWITCH_1.etl” (BASE + CSWITCH these are the “keywords”)
xperf boot_BASE + CSWITCH_1.etl
We can start browsing. What we have seen evokes sadness:
Explorer is ready for the 36th second, but due to 100% download of single (not very fast) drive system for another 2 minutes it will be not very responsive (Start menu opens instantly, but with the launch of the programs will have to wait). ReadyBoot tries to do something and at first it even gives (orange and green), but gradually accumulating deviations from boot reduce its attempts to zero.
Even, it is sadder that instead of actually reading the data, much of its wholly busyness a drive spends in tossing the head to the center of the disk and back:
A small note: ReadyBoot collects usage profile of drive at every boot and then a service SysMain builds boot plan based on the last five downloads. Accordingly, than often we boot, the better would be “guessed” boot plan at the next boot and the faster it will be. In addition, the prefetcher collects statistics about which files and in what order were used at download time and adds this information to % SystemRoot% \ Prefetch \ Lawet.ini
This information uses a built-in defragmenter to make decisions about placing files.
Accordingly to first “optimization” will be multiple reboot and defragmentation. It is very convenient that xbootmgr can do it for us.
By default, runs six reboots:
After the second start defragmentation:
When it is done in the directory from which we started xbootmgr will stay 6 files with the traces, each from the preparatory reboots and still the same boot_BASE + CSWITCH_1.etl
Let's see if anything has changed. But things have changed quite significantly:
ReadyBoot does its job much better and as a consequence of an explorer is ready for a one third faster, and the time of drive activity was reduced by almost half.
We still go to the center of the drive, but the drive seek is much smaller, and this is already some success. In the meantime, let us pay attention to such schedule:
It's a disgraceful. As long as someone is laid out at 100%, some rest. As usual exchange the process time on the size of the data being read. It is correct to use the compression. We correct the folder compression both Windows and Program Files. Attempt to do so from the booted system cannot be called successful - some files are packed, the other is not:
We reboot in the System Recovery and carry out compact / c / a / i / s: a directory for our three directories. Screenshot for WinPE would be better double check experimentally. PrepSystem has to be leading one more time, since the drive lawet after compression greatly changed.
Let us check what we have left:
Explorer ready for the 20th second, even a little less than a minute goes drive activity, but a little less than 100%.
Yes, we still go to the center of the disk:
Tooltips give us a problem. Recheck.
At the same time, under the distribution gets Skype and other. They can always be run from superbar / start menu.
Totally is irresponsible at download time of one service:
We do not reject the functional, so we will not disable the services. We just switch them to «Automatic (Delayed start)»:
In the case of Microsoft Antimalware is all a bit more complicated:
Enough quickly find out that the service belongs to the group “COM Infrastructure” and cannot be boot later in this group. We go into the registry and take out it from this group, and then we finish the work.
Just in case is another prepSystem and this is end:
Explorer booted on the 17th second, and on the 18th actually stops drive activity.
We can enjoy a strictly ordered access to the drive
Fast SSD and / or a total cut out of the functional would reduce the download time up to ten seconds or less.
The conclusion is:
Before any “optimization” needs to identify the minimum changes, which will have the maximum result.
|Vote for this post
Bring it to the Main Page