3 ms·
I'm aware of the mechanical I/O bottleneck, and I'd love to have SSDs in the machines I use, but funds do not permit. But I doubt that's the whole story. The f
by Lagged2Death 15y ago
I'm aware of the mechanical I/O bottleneck, and I'd love to have SSDs in the machines I use, but funds do not permit.
But I doubt that's the whole story. The first time I type "Ctrl-F" in a VS2010 session, the disk thrashes and there's a noticeable delay of a couple of seconds before the Find tool loads. The delay is so bad that keystrokes are lost; if I not-particularly-quickly type "Ctrl-F mystring", the find tool searches for "tring."
I'm sure an SSD could improve that situation, but the real issue here isn't that the disk is slow, it's that the software is causing disk access where none should be necessary.
I'm sure there are reasons behind it; the find tool is a module in a modular system, it's not hanging around when it's not needed, it makes a smooth fit with the rest of the framework that was used to build VS2010, etc.
But the end result, the end user experience, is worse than it was in older, simpler versions of the product. (In this particular way, it's actually worse than a DOS-era editor, running on far more severely bottlenecked hardware, was 20 years ago.) The find tool was probably built in whatever was the most straightforward way to get it to fit into the horrendously complicated system (VS2010 on Windows) it's a part of, and no effort (or not enough effort) was expended to make it any better than that.
This is just one example that struck me today. There are plenty of other situations where a Windows machine full of Windows apps will cause the user to wait in situations that shouldn't require waiting. You can classify them as I/O bottlenecks, and that's not wrong, but I think it's missing the point. Everyone knows there's an I/O bottleneck there; when you develop code, you're supposed to bear that in mind.
But backwards compatibility and shipping the damn thing are more important than optimizing, and that goes for Windows itself and all the components thereof as well. The stuff we write today has to accommodate the foolish-in-retrospect decisions of yesterday.
- rogerbinns 15y agoThis complaint is the reason why some apps include "quick" loaders under Windows. Effectively they have a tray icon, run after startup and load the files making up an app so they are already in memory when you run the app. Then when you launch the app for real it appears very quickly including all the functionality. Of course people get annoyed at these things, taking up "memory", "delaying" system start etc and get rid of them. I/O just tends to be more expensive on Windows. Not only does the code have to deal with backwards compatibility, old drivers and tag alongs (anti-virus, backup), potentially obstinate hardware, and numerous other things but often the OS is supported for a long time. For example Windows XP uses a 10MB buffer cache, irrespective of how much RAM you really have. (Can be changed via registry, code changed in Vista.)