Bug of the moment 2007-05-23
I have been sat on this one since February and was not sure whether or not to write about it or not, but I guess it’s worth a shot; it’s a while since I’ve written an epic. My memory of what exactly I was doing is thus a little bit hazy, so details may not be precise.
I do not know how NTFS handles file times (aside from storing dates back to 1601), but it appears to transparently account for daylight saving time. The timestamps on all the original screenshots are one hour ahead of the times shown in the screenshots, presumably because daylight saving time is presently in force, but was not back in February. I am not sure if this is a positive feature or a flaw.
Premise
Apple decided that Safari would store (and I quote) “about a week’s worth of webpages you have opened”. I use the iMac irregularly so I would really appreciate items staying around for a while longer. The virtually non-deterministic imprecision of the documentation both worries and amuses me. I also thought that Safari had no history viewer at all (and no-one argued to the contrary) but I just noticed that the documentation tells you to find it in the bookmarks window! (The first place I would look for my history of course.)
Firefox takes a more conventional approach to history, but in order to accommodate the sort of timescale I desire (at least 40 to 60 days) it does become rather clogged up. The Extended History Manager extension allows one to easily round up and delete items en masse, so sometimes I try to speed up the history by removing unwanted addresses. It was trying to remove all older Geek Culture forum page addresses that I discovered a slight problem with the complexity of history deletion.
Life on Windows
I have been running Microsoft® Windows® 2000 since summer 2004: nearly three years. It was something I never foresaw (being an avid Macintosh devotee and evangelist and Windows hater). I am not quite sure what a nerd like me is doing running Windows, but then, Sony’s rootkit was discovered by a great Windows user (Mark Russinovich), so clearly even the heroes of the technology world are allowed to run it!
Windows is a strange system, and it has both its advantages and its disadvantages. Explorer alone seems to contain a great deal of both.
I asked Extended History Manager to delete a very large list of history items, causing Firefox to promptly lock up. (Firefox, like most graphical browsers, is a great example of how not to do threading – plenty of threads and distinctly non-threaded behaviour.) Never mind, I can ignore Firefox for a while.
I tried to launch some program or other via the Start menu, and here the problems began. If Firefox is not responding or is suspended, the taskbar will also lock up if you try to launch a process:
So until Firefox finishes deleting my history items, I have no taskbar. The first sign that this is going to take a long time, is when Firefox throws up an unresponsive script error:
I imagine the taskbar was out for at least ten minutes at this point. Suffice it to say that I was well acquainted with this dialog box by the end of the evening.
To err is human
A friend gave me a link via instant messaging, which I mistakenly clicked. Of course, there is no use trying to open a Web page when Firefox is out for the count:
That error message is a bit iffy however. I would understand if gaim reported that Firefox was unresponsive, but it looks like we have our first example of a certain boolean condition in the wild. Did the process respond to our URL launch request? Yes? No? FileNotFound.
Despite having DDE set up for this action, gaim (now Pidgin) uses the older and rather awful model of simply launching a new copy of the relevant program and having that program seek out and communicate with the existing running copy. So now I had a second copy of Firefox sitting there and unable to quit:
It refused to close cleanly (since process closing is another crawling horror in Windows) so it got, in the words of Monzy’s nerdcore performance, kill -9:
Behind the scenes
Something like twenty minutes had now passed, and this was starting to look rather broken. I started to investigate a little. I don’t remember any more how I made this discovery, only that I did. Here are three screenshots of the Firefox history database in close sequence:
Note that the file size is rapidly increasing. If you switch the folder window to details view and keep refreshing it, the history.dat file is being repeatedly truncated and rebuilt from scratch. It would appear that the history item deletion process entails deleting each item one by one, and rebuilding the history database in the process. If you need to delete a few tens, hundreds or thousands of items, that history database is going to get rebuilt over and over tens, hundreds or thousands of times. Its ress mass is only 5 megabytes but it all adds up. At this stage of the IT industry, has it really come to this? There is no piece of suitably-licensed stock code anywhere that can manage a history database with a slightly more efficient item removal process?
Appointing blame
I cannot deny that running a Pentium II computer contributed to this, but that is not the only cause. Deleting a noticeably smaller number of items from the History sidebar just now took about twenty minutes, and the original run in the screenshots took at least half an hour and probably an hour or two. A computer ten times as fast could have not done better than three minutes which itself is beyond an eternity in human perception. Thirty times as fast would give you a whole minute, which is more tolerable if the process had been threaded properly.
I have no idea what the speed difference is between my Pentium II 333 MHz computer and a reasonably modern machine. Clock speeds are not up to thirty times faster (10 GHz) but there will be greater cache sizes, faster drive interfaces, multiple processor cores and perhaps even operating system enhancements to factor in, so it is reasonable to imagine that the developers of Firefox don’t notice a thing. I am reasonably certain however that a decent algorithm would have fared better!
When I think of all the computers being thrown into skips and landfill sites and cussed out by people for their slow and outdated performance, the artificiality of this obsolescence always hurts. It is our own doing as incompetent software developers that condemns older computers to their deaths. Plenty of folk cannot afford even an old computer, let alone a brand new Macintosh, and we consistently underestimate how much power truly exists in even the slowest of machines. After all, people were able to successfully perform word-processing with spell-checking on 8-bit home microcomputers!
As to why the built-in History sidebar behaves identically even to the point of throwing up “Unresponsive script” errors, I have no idea. I don’t know if Extended History Manager has infiltrated the regular history manager and busted it, or whether JavaScript-based history management and complete history.dat regeneration are part of Firefox itself. I would not be too surprised.
Posted 23rd May 2007 – Comments and questions?