Index.dat Part IV – It’s doing what on the UI thread?

Whenever someone kills an application because it is hung we get a little report with the stack and some other information (if the user chooses to send it).  About 1% of the reports for IE are from users who have killed IE (or the Internet Control Panel) while it was clearing the cache.  This is only slightly related to index.dat; I am using this series of postings as an excuse to talk about it on the assumption that someone might find it interesting.

In IE, Tools->Internet Options->Delete Files…->OK.  Depending on how big you have set your cache and how long it has been since it was last cleared, this little operation can take a long time.  I have personally seen it take as long as 20 minutes, which is a long time to stare at the little hourglass cursor.  Of course the Internet Control Panel dialog is modal to the IE window, which means you cannot get back to whatever you were doing in the IE window until it is done.  And if you click on things like the title bar, etc, as most people do when some program is taking an infuriating amount of time to accomplish something, Windows appends the [not responding] text to the title text.  So people kill it.

The moral of this story is known to us in advance, I think: do not do blocking stuff on the UI thread. 

It is an interesting problem though.  The solution is not as straight-forward as one may initially think.  The obvious thing to do is to spin up a background thread and have the cache-clearing done on the new thread.  Assume that has been done; you open IE, clear the cache, the thread kicks off, you close the inetcpl, you close IE, you shutdown your computer.  Did the cache get cleared?  You asked for it to be cleared but you do not know for sure.  What if it was still going 20 minutes later when you shutdown your machine?  There are privacy implications here–I want to know when it has finished. 

A proper solution would implement some sort of feedback, like file copy operations or the file download dialog in IE, that can live in a non-modal state even if the parent IE window has closed.  Which is probably why nobody fixed it in previous releases–bigger fish to fry. 

Comments (10)

  1. Adam says:

    The real bug is there is no way it should take 20 minutes.

    rmdir /s on the appropriate directory aint nearly that slow — so is there a huge performance bug in the database engine that IE is using for index.dat?

  2. Yea, I’m wondering the same thing: Why does it take so bloody long in the first place?

  3. jeffdav says:

    I am not familiar with the inner workings of what wininet is actually doing, but I suspect they need to grovel through everything and make a decision about whether to clear it or not. IE is not the only application that uses the cache, and even within IE there are different ways of clearing the cache. If you do not check the "Clear offline files too" checkbox on the Delete Files dialog, then Favorites that have been made offline files are saved, because you want them to be available offline.

  4. CN says:

    Still, it would seem that there is perharps a square runtime (or at least > linear) behavior here, i.e. each deletion being proportional to the total number of elements in the cache.

  5. jeffdav says:

    Not sure what its time-complexity is. Having lots of small files makes it take longer then a few big files, which we would all expect. Like I said, I am not sure… this component is way below the code I write in the stack. I am just a consumer. My job is to fix the doing-it-on-the-ui-thread problem, not the it-takes-for-ever problem. :)

  6. So it’s more an issue of IE’s massive integration than anything else…

  7. jeffdav says:

    No, integration is not the issue. You have to have a cache, you have to have a way to clear it. The issue is doing blocking operations on a UI thread.