The code to manage "do I sort or do I cache" is probably worse than the code to just sort it unconditionally.

And you really want to do this automatically, with no manual anything, because (among other reasons) if you need to swap a part on a broken machine, you do not want that to needlessly break the software. So you're sorting regardless, and so you might as well just be unconditional about it.

on my machine TPM is checking state of machine for security reasons, so if this runs ANYWAY then why not use that for one more useful thing ... ( it runs before even machine thinks about booting anything )

you can define shutdown flag for hardware change: shutdown -rF XD,

some things are hot swappable and for that there has to be logic (in kernel) to know you have new hardware...

if you have total hardware failure that can be detected too, on next boot...

> toggle switch in control panel before restart

Ah yes, let's brick the OS when hardware fails and has to be replaced without advance notice.

im not saying remove all existing code,

im saying you can have two pathways, ( decision which route to choose is almost zero cost )

first - when you boot correctly, you can save information that you booted correctly.

second - if you do not find information about safe boot, you go old route, quicksort route.

( YES. you can do that, in a way you do not have loops of boot process because you are reading boot is ok even if it is not. just dont be lazy like linux kernel developers were, when i was telling them this exact thing few years back. )

But why? You have a very manageable number of devices, O(nlogn) over that on a modern processor is absolutely zero time.

That's nice way to add fuckloads of useless code while wasting memory and making now-read-only process into read-write process (kernel have no place to write cache before userspace initializes and sets up mounts and filesystems).

...vs just putting quicksort in

Windows XP had a tool called BootVis[1] that would try to optimize the startup sequence. Supposedly newer versions of windows do this sort of thing automatically.

I suspect much of the delay comes from the nature of plug-and-play. The OS has to poll every bus and every port to find every device, then query those devices to determine what they are, then load a driver and actually configure them. It simply can't rely on the hardware being exactly the same from one boot to the next.

[1] https://en.wikipedia.org/wiki/BootVis

Phones take a long time to boot (12 seconds on an iPhone SE) even though their hardware stays the same.