Hacker News Reader

Comment by johnchristopher | Hacker News Reader

What ? I still do that at least once a week/month.

Last time it was for the linux dropbox updater, last week.

I am also a fan of using another window so I can use the mouse and still have a marker to monitor progress.

I do this all the time too, but unfortunately many processes today only go around in circls instead of showing the actual progress.

to be fair, "actual progress" is almost always a misnomer anyway.

When I implement progress bars I most often implement "pessimistic progress", so "considering all timeouts, worst case we are 46.5% (of the time) to some result", with an update every few hundreed milliseconds. As possible mix in data from completed subtasks.

Nobody ever complains if the process suddenly speeds up because progress was made before the timeout, as long as your initial estimate wasn't absurd (looks at Windows Explorer). Even a naive progress bar counting down the 60s timeout is more informative and satisfying to watch than an endless spinner.

Absurd initial estimate? All of the estimates tend to be absurd.

Done in 30s ... I mean 15min ... ah, 10s ... 1hr 7min ...

Oh, come _on_ ...

Windows 95/98 used to occasionally do some particularly insane estimates. I took this screenshot many years ago of copying a tiny NetHack install between drives: https://i.imgur.com/q7tc9R1.png

Vista, I think it was Vista, "fixed" that by adding an estimation pass first, that often took longer than the copy itself, and was almost as bad at estimating. It sometimes took much longer. The fix was far worse than the problem, yet it survived unchanged.

It was so bad I ended up discovering Teracopy which was decent at estimation, and far faster at copying. Was a must-have until I migrated away from Windows.

How exactly do utilities like Teracopy implement high-performance copying? In other words, what are the performance bottlenecks in explorer.exe? Personally, I've observed that:

1. Explorer attempts to do a file enumeration prior to copying, which sometimes could waste a lot of time.

2. It seems tools like Teracopy use buffering aggressively, which can speed up the copying significantly based on my experience on Windows XP with slow HDDs.

Are there any other points worth noting?

Single pass and aggressive buffering seems to cover what I remember, but it worked better than it I expected, even on high speed drives or SSD to high speed drive. They may have had other tricks, it's been a while now.

The other thing that I liked is it's non-blocking - you can continue doing copies while one is in progress, if it's to the same destination it gets added to the queue in progress. If different destination it goes in a new queue that waits for the first to finish.

We used to call these "Microsoft Minutes"...

I find the Progress bar is usually about as accurate as the Time Remaining calculation. Both are better than nothing but more of a fiction than reality.

True! I know some of the people involved in the windows update bar. Since cpu and dusk are so different across devices it’s hard to know actual time it will take. Instead teams divided their packages into theoretical weights and the progress bar showed the percent of total “weights”. That’s why it can be choppy is packages with few subdivisions have little to interpolate.

With a process that happens on regular intervals like a Windows Update, I always wondered why the system doesn't store metrics on how long the process has historically taken on previous runs, and then just uses a weighted average of historical times as a time-based total estimate, converted into a divisor for work-based progress estimates (i.e. if previous runs took 60 minutes on average, then progress at 25% would say "45 minutes remaining", then if it suddenly jumped to 50% would immediately say "30 minutes remaining." Even if they're choppy, those time estimates would actually be correct if you sampled and averaged them.)

Not sure if anyone's mentioned this yet, but the old original Mac OSX boot screen had a progress bar that was based on the exact length of the previous boot time.

Progress indicators that moving perfectly and steadily are probably time based, but I'd have thought they've always been work based. Example: you know you have to copy 20GB across the network; update the progress bar with 'percent of data complete' periodically (on a timer, in the byte copying loop, whatever.)

I've seen dual progress bars: one for "overall progress" (each one of five tasks fills this bar 20%) and one for the current task (maybe downloading, maybe unpacking, maybe copying, maybe waiting for hardware to reply...)

I've written progress bars that combine all of the above. Each sub-task had a weight though, and adaptive interpolation was used to animate the progress bar between chunky updates from less granular tasks based on how far they usually increment over which time interval.

We pushed "progress bar" data to the client via SignalR once x% of a slow moving process were complete.

I guess what has changed is me, not the computing environment. When I was young, I easily grew impatient when things were going slow. Nowadays I still kinda feel nervous, but not to the point to warrant such bookkeeping methods.

My urge to measure everything has only grown with age. I don't chalk it up to nervousness though. I'd say it's driven by curiosity and and a desire to forecast.

Today everything goes so fast that it's faster to kill and restart if it's not visibly moving, IMHO

Reply on news.ycombinator.com