Who created the score?

In a Stanford interview, Tsachy Weissman credited his former graduate student Vinith Misra with devising the formula for the show's first-season finale.

Has it been used outside television?

Yes. Dropbox included it in a 2016 engineering discussion of Brotli, alongside concrete performance measurements.

Is there a universally meaningful target score?

No. The value depends on the baseline, scaling, dataset and measurement convention. A target detached from those details is not a useful performance requirement.

AI Glossary / MLOps and deployment / Intermediate

Weissman score

Definition

The Weissman score is a compression-comparison metric that combines compression ratio and compression time relative to a baseline compressor. It originated in advice for the television series Silicon Valley and has also appeared in real compression discussions.

What it means

Compression involves competing objectives. A smaller output may take longer to create, use more memory or take longer to decode. A single score offers a convenient summary, but it necessarily gives some tradeoffs more importance than others.

The Weissman score combines size reduction and encoding time using a particular mathematical rule. In the conventional formulation, a higher score indicates a more favorable combination under that rule and the stated benchmark conditions. It does not establish that a compressor is best for every application.

Its television origin does not prevent calculation on real measurements. Equally, its use in an engineering article does not turn it into a universal industry standard. Treat it as a named comparison formula whose assumptions and limitations must accompany the number.

How it works

A commonly presented formula is W = alpha × (r/r0) × (log(T0)/log(T)). Here r is original size divided by compressed size, T is compression time, and r0 and T0 describe the baseline on the same input. Alpha is a chosen scaling constant.

The baseline compared with itself scores alpha, provided the logarithms are defined and nonzero. The logarithm's base cancels when the same base is used throughout. However, changing the units used to express time does not cancel in general.

A careful calculation therefore declares a reference time unit and takes logarithms of numerical time values relative to that unit. Candidate and baseline times must use the same convention. Times equal to one unit create a zero logarithm; values below one can produce negative logarithms and misleading interpretations.

Benchmarking also requires a declared dataset, compressor settings, hardware and timing procedure. Verify exact decompression separately. This formula contains no term that proves correctness or accounts directly for decoding speed, memory consumption or deployment compatibility.

Three practical examples

A compression researcher reproduces a published comparison using its exact baseline, timing units and scaling constant.
A technical reviewer checks whether an impressive score reflects smaller output, faster encoding or an altered benchmark convention.
A storage team records the score alongside raw measurements, then makes its actual decision using the workload's storage, transfer and processing needs.

Think of it this way

Think of a sports contest that combines running and throwing into one points total. The scoring rule determines how much a faster run compensates for a shorter throw.

A high combined total is meaningful within that contest's rules. It does not identify the best athlete for every sport. Likewise, a compression score cannot choose the right balance for every service, and inconsistent measurement units can undermine even the within-contest comparison.

Worked example

Seeing why the time convention matters

Use an original 100-megabyte test file. An invented baseline produces 50 megabytes in 100 seconds, giving r0 = 2. A candidate produces 25 megabytes in 10 seconds, giving r = 4. Set alpha = 1 and use base-ten logarithms with time measured relative to one second.

The score is (4/2) × (log10(100)/log10(10)) = 2 × (2/1) = 4. The baseline scores 1 under the same convention.

Now express those identical durations relative to one millisecond. The numerical times become 100,000 and 10,000. The calculated score becomes 2 × (5/4) = 2.5.

Neither compressor changed. The output sizes and elapsed durations are identical, yet the score changed because the time normalization changed. This is why a bare score cannot be compared reliably across reports without their conventions.

The candidate genuinely halves output size and takes one tenth of the baseline's encoding time in this invented example. Those raw comparisons remain understandable regardless of the chosen time unit. No real compressor performance is claimed.

Illustrative case study

A fictional archive-software team receives a proposal advertising a much higher Weissman score than its existing system. During review, it discovers that the two reports used different datasets and different units inside the timing calculation.

The team reruns both implementations on an agreed corpus and reports compressed size, encoding time, decoding time and peak memory separately. It keeps a consistently calculated score as an additional reference, but the archive's frequent restore operations make decoding performance particularly relevant.

The proposal is evaluated against those actual requirements. This fictional case illustrates a measurement problem: a mathematically calculated number can still be an unsuitable basis for comparison when the conditions differ.

Common misconceptions and mistakes

A Weissman score is not a compression algorithm or file format.
Doubling the score does not necessarily halve file size or double speed.
Matching logarithm bases does not solve dependence on the time unit.
A television score should not be treated as a real-world performance ceiling.
Lossless reconstruction must be established independently of the scoring calculation.

Business use

The useful business lesson is to examine the measurements behind a benchmark. A service that compresses once and decompresses repeatedly may value different properties from one that compresses a live stream under a strict deadline.

Specify the operational constraints first, then compare candidates that meet them. Record actual bytes saved and the relevant processing costs, including memory and latency. If a supplier uses the Weissman score, request its formula, baseline and timing convention. This makes the claim reproducible without assuming the score's tradeoff matches the organization's priorities.

Check your understanding

Two reports use the same compressor and file but express time in seconds and milliseconds inside the score. Must their Weissman scores match?

Answer: No. The ratio of logarithms generally changes when both time values are multiplied by the unit-conversion factor, even though the actual performance is unchanged.

Related terms

Benchmarks
Lossless compression
compression ratio
benchmark
throughput
encoding time
decoding time
performance metric

Learn next

Plot compressed size against encoding time for several settings of one compressor. Identify settings that another setting beats on both measures, then examine the remaining tradeoffs without immediately collapsing them into one score.

Sources

Sources: Stanford interview with Weissman: https://news.stanford.edu/stories/2019/12/qa-stanford-faculty-silicon-valley . Dropbox's engineering account: https://dropbox.tech/infrastructure/lossless-compression-with-brotli . Jeff Kaufman's original formula analysis: https://www.jefftk.com/p/weissman-scores-useful . Relevant attribution, usage and formula passages were reviewed. The unit-conversion calculation is an original illustration of the stated formula.

Previous: Weiss intrinsic-image estimator Next: Welch's t-test