I certainly get a slightly longer delay the first time in a session I use it: the disk light goes on, and the UI thread appears to be blocked. Which is odd on the face of it, as all the rest of the time that feature is very clearly non-blocking. What I suspect is going on, is that at that moment it scans the whole history database (on Unix, ~/.mozilla/firefox/<i>profile</i>/places.sqlite), pulling in all the pages and generating so much disk I/O that when the UI thread then hits a non-resident page and pages it in, it has to wait in an I/O queue.

A defragmenter would probably help, but apart from that what you really want is for the history-database thread to have lower I/O priority than everything else -- on Linux this is ionice(1) or ioprio_set(2), but I don't know whether Windows or Mac has equivalent settings.

Peter