Tech Behind ThingsHow the ordinary machinery actually works

Software

Why A Progress Bar Is Usually Guessing

Progress indicators estimate completion from a quantity that rarely tracks the remaining work, which is why they stall at high percentages and jump backwards.

Vibrant and engaging code displayed on a computer screen, showcasing programming concepts.
Photograph by Seraphfim Gallery via Pexels
Editorial note. Independent reporting and analysis. Nothing here is sponsored or paid for. How we work.

Progress bars behave in ways that would be absurd for a genuine measurement, racing to most of the way and then stopping. They are estimates built from convenient proxies.

The measured quantity is rarely the real work

A bar needs something countable. Files copied, bytes transferred or steps completed are available, and each is a poor stand-in for time remaining.

Copying a thousand small files takes far longer than one large file of the same total size, because each file carries fixed overhead the byte count does not reflect.

The bar advances smoothly through the bytes and stalls on the overhead, which the user experiences as the operation freezing at ninety per cent.

Some phases cannot be measured at all

Installers finish with steps of unknown duration, such as registering components, rebuilding caches or waiting on another process.

Nothing countable exists during those phases, so implementations either freeze the bar or move it at an invented rate.

This is where the final portion of many bars is pure animation. It is honest about the state of the system and dishonest about the meaning of the display.

Rate estimates chase a moving figure

Remaining time is derived by dividing outstanding work by observed rate, and that rate fluctuates constantly with contention and network conditions.

Using a recent average makes the estimate jumpy, while a longer average makes it slow to notice that conditions have changed.

Neither choice is satisfactory, which is why estimates swing between implausible extremes early on and settle only when little work remains.

Total work is sometimes discovered while running

An operation that must walk a directory tree does not know how much there is until it has looked, and looking is itself a large part of the job.

Implementations either scan first, delaying the start while showing nothing, or begin immediately and revise the total upwards as they go.

The second choice produces a bar that goes backwards. It is more informative than the alternative and looks like a defect.

Perception is designed for deliberately

Research into how people judge waiting consistently finds that a bar accelerating towards the end feels shorter than one moving at a constant rate.

Some implementations therefore apply a curve to the displayed value, meaning the position is a presentation choice rather than a report.

An indeterminate spinner is the honest alternative, and it is used sparingly because an interface admitting it does not know tends to be read as broken.

Questions readers ask

Why does a copied folder show a different size?

Block allocation, compression and metadata differ between filesystems. The contents are identical while the space consumed is not.

Is defragmenting a solid state drive useful?

No. There is no seek penalty to remove, and rewriting every block consumes write endurance for no measurable benefit.

Softwarestoragesoftwareoperating systemsdata
Junko Ishida
Contributing writer, Tech Behind Things

Junko covers batteries, charging and energy density, and is unimpressed by most battery claims.

Also by Junko Ishida