throughput
Picture a toll booth on a busy highway. You can ask two different questions about it. How long does one car take to get through the booth — pull up, pay, lift the barrier, drive off? Or how many cars get through per hour? The second question is throughput: the rate at which finished work comes out the end. A booth might take each car six seconds (that is its latency) yet still process 600 cars an hour if cars line up and flow steadily.
In computing, throughput is the amount of work completed per unit of time — instructions per second, requests per second, frames per second, gigabytes per second moved across a bus. It is the metric that matters when you have a long stream of independent work and you care about total volume rather than any one item. A pipeline is the classic throughput trick: by overlapping instructions so several are in flight at once, it raises the completion rate even though each individual instruction takes just as long as before. Throughput is sometimes called bandwidth when we are talking about data moved (bytes per second) rather than tasks finished.
The honest pairing is throughput versus latency, and they are not interchangeable. Adding more workers (cores, lanes, toll booths) usually raises throughput but does nothing for the latency of a single job — one car still takes six seconds even with ten booths open. Worse, techniques that maximize throughput, like batching jobs together to keep hardware saturated, can lengthen the wait for any single request. A warehouse-scale datacenter is engineered for throughput across millions of requests, yet still has to fight to keep tail latency low so that no single user is left waiting too long.
A server handles each request in 50 ms (latency). With one worker it finishes 20 requests per second. Add 8 workers running in parallel and it finishes about 160 requests per second (throughput up 8x) — but each individual request still takes 50 ms. More throughput, same latency.
Parallel workers multiply throughput while leaving the latency of any single job untouched.
Do not collapse throughput and latency into one 'speed'. They optimize differently and can trade off against each other; the right one depends entirely on whether you care about total work done or how soon one job finishes.