8

TL;DR my hard drive combination is causing load dialogs to take ~6 seconds to load, which is also confirmed via code, and I can't find any relief.

I had Windows 7 for a long time, ignoring 8 entirely. So long as I was on 7, I had to endure a very long startup time, but otherwise was satisfied with performance on everything.

Right before Windows 10 was released, I bit the bullet and got it installed so I could at least attempt to keep up with the times. At the same time I got a new SSD to install it on to alleviate my startup woes. Everything installed much more smoothly than I had hoped, and I was back up to speed in no time. The growing pains were all but nonexistent, except for a single thorn in my side: occasionally, when I pulled up a load dialog, it would take ~5-10 seconds before even appearing.

(Before you jump up and say "power profile", that not it, it's set to never spin down the hard drives.) I only say "occasionally" because it took me a while to figure out which programs were doing it--at first I think it was everything, but Chrome and others seem to have had the behaviour patched out of it. The big one that still produces the behaviour every time is Gimp 2.8; no matter what I do, if I save a new file or go to load, I have to wait 5-10 seconds for the dialog to pop up.

At first I thought it was a bug in Windows 10 itself, but then as Chrome et al got better, I figured it must just be something with Gimp, which wouldn't be the first oddity I've run into with that program. But then I was brought a bit closer to the hardware and I discovered it was not Gimp's fault.

I do Unity game programming, and I'm currently working on a general purpose save/load dialog using C# (and outdated Mono libraries). When I first got the file browser to work, it was slow as molasses--I chalked this up to a poor method on my part, but as I got to optimizing it, I discovered that the vast majority of the wait time was caused by a single line of code:

string[] drives = System.IO.Directory.getLogicalDrives();

After measuring it, this delay was equivalent to Gimp's slowdown: 5.5 seconds, all for Windows to say "you have a C:, D:, E:, and F: drive". I hacked a modification to my load dialog so it would display this drive info delay, and confirmed that every single time the program is run, I have a ~5-6 second delay. Just to hear back from a System API call to get a list of hard drive paths.

To put into perspective just how bad that is, I ran this same program linked above on my wife's laptop, my brother's laptop, my father's desktop (all three on Windows 10), and my mother's mac mini (after recompiling for a MacOS target). On each and every one of them, the delay is in the 10s of milliseconds, exactly what I would expect. The mac mini took about 20 seconds just to load the damn program, but once it was running, boom, less than a tenth of a second to load the hard drives from that single line of code.

So now I'm at a loss. The power profile is set to not ever power down the drives; my BIOS is set to AHCI for the SSD; I have set the page file to not be dynamic; I've disabled indexing and the Windows Search service; everything is defragmented. I even booted back up into Windows 7 to see the state of things; none of the programs had any kind of load dialog lag, but when I ran my little load tool, it consistently showed 5.5 seconds to load the drives.

I should note that during those 5 seconds, there is no huge spike of CPU/memory or disk access; here's a screenshot of the program moments after running, with task manager there in the background: imgur link.

Here is a screenshot of disk management: imgur link. Disk 0 is the SSD, Disk 1 a recent 1 TB drive, Disk 2 an older Caviar Black 1 TB drive, and Disk 3 a Caviar Green 2 TB drive (never again; it has built-in 20-minute disk shutoff. I'm reasonably sure it's not the cause of this, as repeated tests all still each have a 5 second delay).

Does anyone have any insight for anything else I can try? I'm basically reduced to booting with some of the drives disconnected to see if any individual drive is somehow causing problems (though I tried setting all but disks 0 and 1 offline in disk management, to no avail). Any help would be most appreciated.

EDIT: Some further findings: After disconnecting all HDDs (including my blu ray drive, leaving me with only the one SSD), the problem persists. After completely disconnecting the internet, and disabling network discovery, the problem persists.

In addition, the 5.5 second mark seems to be a rock solid number. The "Disk Walk" time of my tool (which is how long it takes for the first level of directories of each disk to be read) varies wildly, while the Disk read time is always in the 5.550-5.580 range. This seems to indicate some sort of 5.5 second timeout is happening somewhere.

EDIT 2: I booted into Windows 7 with just the 2 1TB drives connected. Load time is still slaved to the 5.5 second wait, even without the SSD involved, which kills my leading theory on the root cause. This suggests to me that perhaps there is an issue with the motherboard's input drivers, maybe?

My hardware, just in case it ends up being pertinent:

  • Processor: AMD Phenom II X4 965-Black
  • Motherboard: Gigabyte GA-790XTA-UD4
  • Video: AMD HD 5770
  • SSD: OCZ ARC 100 240GB
  • HDD: WD Black 1TB (2013)
  • HDD: WD Green 2TB (2011)
  • HDD: WD Black 1TB (2010)
4
  • Nice to see some evidence that this isn't GIMP (or the GTK+ file chooser dialog). We are getting reports from some users who have migrated to Windows 10 about the delay, but this was not uniform across the user base. Sep 29, 2015 at 10:20
  • @MichaelSchumacher I take it that you guys were unable to narrow it down further than "some gimp users on windows 10"?
    – ketura
    Sep 29, 2015 at 17:03
  • Exactly. To be honest, I don't think anyone tried... so far, it seems to affect a minority of systems (as you have discovered yourself), and a family of platforms none of the main contributors are using much. Sep 29, 2015 at 18:58
  • 1
    @MichaelSchumacher I've figured out both our problems. Ethereal floppy drives timing out is what's causing the delay. Point any users with that problem to disable the floppy drive completely in BIOS and the problem should hopefully evaporate. If they don't have that option...may God have mercy on their souls.
    – ketura
    Oct 1, 2015 at 5:40

2 Answers 2

8

Gorram son of a businessman.

It was the nonexistent floppy drive. No-one ever expects the drive they don't have!

My motherboard has a floppy controller on it, which apparently as a technology hails from the era where checking to see if anything is connected was considered a waste of clock cycles. Each and every time I ran System.IO.Directory.GetLogicalDrives(), it was waiting for the ghostly drive to timeout.

I opened up my BIOS and found a setting to disable the floppy altogether, which has caused the problem to completely evaporate. Gimp now loads flawlessly, too.

I'm such a fracking good detective.

5
  • Excellent. Did you check whether this was already disabled on the systems that didn't exhibit the delay? Oct 1, 2015 at 11:56
  • 1
    Two of them are laptops, and one was a mac mini, so they don't have the capacity. I'll check the other desktop once I have access to it. EDIT: Hmm, though I suppose I shouldn't put it past a laptop manufacturer to include something like that just because it won't be used. I'll double-check.
    – ketura
    Oct 1, 2015 at 14:03
  • Another thing, just for the sake of completeness: if you enable the floppy in BIOS again, the delay does happen again? Oct 2, 2015 at 5:56
  • 1
    Bleugh, yes indeed; the delay does return. Thanks for making me feel dirty for doing that. One of the laptops didn't have any floppy controller; haven't been around the other computers yet to check.
    – ketura
    Oct 2, 2015 at 15:54
  • 1
    This worked. Disabling "Legacy Diskette" option in BIOS resolved the issue of GIMP appearing to hang / crash when clicking Edit > Preferences
    – Chris
    Jul 25, 2020 at 8:34
8

FYI -- disabling Floppy Disk Drives > Floppy Disk Drive in Device Manager worked for me. I was too lazy to restart and fiddle around in BIOS.

2
  • Legend. Mine was exhibiting the same symptoms as the OP and turned out to be a dodgy SD card that I had left in the card reader. This answer prompted me to think about it! Popped it out and ... all working smoothly again :)
    – Jimbo
    May 3, 2016 at 11:51
  • Upvoted. It makes more sense to me to disable the device on the OS level.
    – steinar
    Jul 18, 2017 at 18:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .