These machines are still insanely fast. If you actually notice anything get substantially slower, you are either running very specialized workloads or you can forward the blame right to the developer of said application.
It seems pretty unlikely that many people have a workload that is highly sensitive to read throughput, has a disk footprint so small it fits on a 512GB SSD, and where the cost of slower disk outweighs a 20% faster CPU.
If I select 200 files and make a zip, that's probably an impacted workload.
As in 20% faster on the M2? At least for gzip defaults the per core throughput on my M1 is around 50MBps.
As in, possibly slower on the M2. Zipping a complex file tree can be disk-constrained, particularly if there are many small files.
For scale we're talking > 2TBps linear read and probably > 500MBps random 4k read in both cases, compared to on the order of 50-500MBps limit on the CPU side depending on threading etc. So still CPU limited. If there's any problem with big file trees it's probably macOS's relatively slow filesystem so again, advantage to the faster CPU. It sounds like LightRoom startup is a little slower but if you use it for editing you're going to get that back in faster workflow. In general modern NVMe has removed disk as a significant bottleneck for normal peoples' workflows, even on Mac. That includes backups, zipping up collections of files, git compaction, etc. What scenario are you imagining here?
I'm imagining the large filetree zip. I've got an M1 mini at home, so I can run a test on that later today. Maybe some parts of Xcode builds are limited by the disk too.
Xcode depends on random I/O, which is reportedly faster.
Brain fart, 2GBps not 2TBps.
The Twitter OP elaborates further down the thread that they're seeing real-world impact on Lightroom. That would be a bummer for me...but I'd probably buy a build with a larger drive. Waiting for confirmation that this is only on the base model.