[mistercow]

This is why progress bars shouldn't try to reflect actual processing (unless they can measure it in a way that maps close to linearly) and instead should be based on estimation. A progress bar should be a way of telling to the user how much longer you think a task will take so that their time perception doesn't slow down. Using it to indicate wait times accurately or precisely is, at best, a waste of time.

I'm currently working on a side project which is a library for driving progress bars using this principle. You give it an estimated amount of time, and your progress bar fills based on that (not linearly; my testing indicates that deceleration results in a shorter perceived time). If the estimate is way off, then it can switch to an indeterminate indicator instead of filling and stopping. To make the estimation process even easier (especially in the face of variation in user environments), it uses linear regression to adjust the estimates to be more accurate.