Accelerate the loading of Windows for fun and profit

Perhaps, to begin with, if you reboot 15 times a year, then any “tuning” of the boot process takes more time than will be won on reboots for the entire lifetime of the system. However, sports interest takes its toll, especially since people are interested in the process of speed optimization. And the download turned out to be the most obvious candidate for examples of how, in my opinion, this very process should look. I’ll say right away that we’ll boot from the 5400 rpm screw, we’ll boot into the “working” system: in addition to the unfinished Vendor krapwari, there is still a lot of any kind of visual studio, antivirus, Skype, Steam, Google ...

About why disabling the pagefile is more harmful than useful - some other time, but for now ...

Specific and generally applicable tips to optimize the OS can not be just as there can be no specific tips to speed up any random program. Just as in individual programs, the work of the entire system can be seriously slowed down 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 we will also use a profiler to find the “bottlenecks” in the operating system (no quotes are really profilers, at the same time sampled and instrumented). Recently, WPA Tools are distributed as part of the Windows SDK . Installing the full SDK is completely optional. You can install only the "Windows Performance Toolkit":


')
We will collect traces using xbootmgr. Of magic, only the autologger is used , which includes collecting ETW traces starting from the winload itself. To call for help, you can enter xbootmgr -help - I will not bring it here. For those who want to assess the scale, you can enter xperf -providers (or logman providers ). Each provider has several “keywords” (keywords), each “keyword” enables / disables several types of events (event).

So, let's begin. Caution, the following command automatically reboots the computer: xbootmgr -trace boot

After rebooting, the folder in which this command was executed will remain the file “boot_BASE + CSWITCH_1.etl” (BASE + CSWITCH are those “keywords”): xperf boot_BASE + CSWITCH_1.etl

And you can start browsing. What he sees brings sadness:



Explorer is ready for the 36th second, but due to 100% loading of a single (not very fast) disk, the system will not be very responsive for another 2 minutes (the start menu will open instantly, but you will have to wait for the programs to start). ReadyBoot tries to do something and at first it even turns out (orange and green), but gradually accumulating deviations from the bootplan reduce its attempts to nothing.
What is even sadder is that instead of actually reading the data, the disk spends most of its 100% employment in throwing the head to the center of the disk and back:

A little help: ReadyBoot collects a disk usage profile on every boot, and then SysMain builds a bootplan based on the last five downloads. Accordingly, the more often you boot, the better the bootplan will be “guessed” for the next boot and the faster it will be. In addition, the prefetcher collects statistics about which files and in which order were used at boot time and adds this information to% SystemRoot% \ Prefetch \ Layout.ini

This information is used by the built-in defragmenter to make decisions about the location of files.

Accordingly, the first “optimization” will be a multiple reboot and defragmentation. Very convenient that xbootmgr can do it for us.

xbootmgr -trace boot -prepSystem
The default is six reboots:



After the second begins defragmentation:



When everything is finished, in the directory from which xbootmgr was launched there will be 6 files with traces of each of the preparatory reboots as well as the same boot_BASE + CSWITCH_1.etl

See if something has changed. And everything changed quite noticeably:



ReadyBoot does its job much better and as a result, the explorer is ready one-third faster, and the drive activity time has been almost halved.



We still go to the center of the disk and we will deal with it later, but disk seek is already noticeably smaller, and this is no longer any, but a success. In the meantime, pay attention to this schedule:



This is a disgrace. While someone is laid out 100%, some rest. We will fix it. How do you usually spend process time for readable data? That's right, compression. We will fix it by compressing the Windows folders and both Program Files. An attempt to do this from a loaded system cannot be called successful - some files are being packed, some are not. In general, you can not live like this:



Reboot into System Recovery and run from there compact / c / a / i / s: directory for our three directories. There will be no screenshots, since I was too lazy to take a screenshot for WinPE - I’ll have to take my word for it (and it’s better to double-check experimentally). prepSystem will have to spend again, since the layout of the disk after compression has changed a lot.

Well, check what happened with us:



The explorer is ready by the 20th second, a little less than a minute there is disk activity, but already a little less than 100%.

And yes, we still go to the center of the disk:



The tooltips tell us the culprit. Rechecked



At the same time under the distribution get Skype and Steam. And rightly so - they have nothing to do at startup with such appetites. They can always be run from the superbar / start menu.

Finishing touches:

Completely insane loading time of one service:



And the second:



We agreed not to abandon the functionality, even if it didn’t rest on our figs. Therefore, we will not disable services. We simply switch them to “Automatic (Delayed start)”:



In the case of Microsoft Antimalware, this is somewhat more complicated:



Quickly we find out that the fact is that the service belongs to the “COM Infrastructure” group and cannot be loaded later than this group. We go to the registry and pull it out of this group, and then calmly finish the job:



Just in case one more prepSystem and here is the final:



The explorer was loaded at the 17th second, at the 18th disk activity actually stops.

You can admire a strictly ordered disk access:



A fast SSD and / or total cut-out functionality could reduce the boot time to ten seconds or less.

And the conclusion from all this is this: before anything is “optimized”, it is worthwhile to determine those minimal changes that make the most of the results .