As I think about this, maybe it really is a Windows vs Linux thing. On raw read speeds, SSD is only about 2-3x faster than HDD. This is barely noticeable compared to the speed from RAM, or for almost anything you could reasonably launch. (Videos are huge, but those are basically streamed anyway)
But, random access reads of many small files scattered across the disc, obviously SSD will do much better. Sequential reads (large files, non-fragmented filesystem) it's not so clear.
Maybe it's simply that Linux, as well as being better at file caching and not wasting RAM, is also better at not being fragmented. Perhaps I have my OS filesystems to thank for my indifference.
On that front I guess it's also saving me money by allowing me to enjoy ginormous cheap discs :)
Hmmm another thought. Linux also (typically and traditionally) does a lot more library reuse thanks to the open source ecosystem. So, there's less DLL hell and fragmentation there. That could be another reason for my not noticing.
Most of my system libraries that any random app needs are already loaded and ready for use after boot.
Yeah - you might be onto something there - I suspect fragmentation matters a lot for the spinning disks. If you've got huge disks in there, you probably have mostly sequential reads for just about everything.
I mean - I also run the ginormous cheap discs. I don't think anyone is saying to load your media library all onto an ssd, it just doesn't matter enough. But the OS/applications are a big deal.
And 2-3x faster is low. For my wife's machine, moving from a 5400rpm spinning disk to a relatively cheap samsung ssd made effective read times about 12x faster. Technically a 5400 rpm drive can do ~75mb/s, but that mostly ignores seek time, and assumes sequential reads. In reality, it was often doing less than 40mb/s. The SSD caps at about 540mb/s, but in reality it mostly does around 450.
It's the difference between having MS teams take ~5 seconds to load, vs more than a minute (locking most of the machine for that period as well).
I just launched Microsoft Teams for Linux on this spinning rust work machine here.
It launched a meeting link (letting me into the room) in between 2 and 3 seconds (one-onethousand two-onethousand)
I last launched Teams on this machine a couple of days ago.
For a "fair" comparison (keep in mind, again, the whole point I was making that RAM dominates these days), I then ran:
sync; echo 3 > /proc/sys/vm/drop_caches
And launched Teams again.
It opened in between 8-10 seconds with ALL OS caching of disc dropped.
I think what you're seeing here is Windows being helped along by SSD making it usable...
It reminds me of the change we made in Hedgewars. We had no idea it was taking 20-30 seconds to launch our gui in Windows since it opened instantaneously in Linux even with all caches flushed. We had to add lazy page loading to get reasonable performance on Windows - it was probably all about NTFS being insanely slow (and maybe crap at laying out data reasonably).
*Edit - I updated my time estimate upwards slightly for teams after testing the flush several times and my own counting skills.
The flush was also a good test of launching firefox, since I did it once between to update nightly, it also opened very quickly post flush. Barely noticeable delay.
But, random access reads of many small files scattered across the disc, obviously SSD will do much better. Sequential reads (large files, non-fragmented filesystem) it's not so clear.
Maybe it's simply that Linux, as well as being better at file caching and not wasting RAM, is also better at not being fragmented. Perhaps I have my OS filesystems to thank for my indifference.
On that front I guess it's also saving me money by allowing me to enjoy ginormous cheap discs :)