Article development led by
queue.acm.org
More important principles to keep in mind
when designing high-performance software.
BY caRY miLLSaP
thinking
clearly about
Performance,
Part 2
in PArt 1 of this article (Communications, Sept. 2010,
p. 55), I covered some of the fundamentals of performance. Performance is a relation between a task and
the time it consumes. That relation is measurable
either as throughput or response time. Because users
feel variance in performance more than they feel
the mean, it’s good to express performance goals in a percentile format, such
as “Task T must have response time
of R seconds or less in P proportion or
more of executions.” To diagnose a performance problem, you need to state
your goals objectively, in terms of either
throughput or response time, or both.
A sequence diagram is a helpful
graphical tool for understanding how a
task’s execution consumes your time. A
profile is a table that shows details about
response time for a single task execution. With a profile, you can learn exactly how much improvement to expect
for a proposed investment, but only if
you understand the pitfalls of making
incorrect assumptions about skew.
Minimizing Risk. As mentioned in
Part 1, the risk that repairing the per-
formance of one task can damage the
performance of another reminds me of
something that happened to me once in
Denmark. It’s a quick story:
