FIT2109 Chap.9 Profiling and Performance
Profiling and Performance
Profiling and Performance applies the debugging evidence loop to resource use. Define a representative workload, metric and environment, measure a repeated baseline, use a profile to locate dominant cost, change one mechanism and measure again while preserving correctness.
A single fast run on a different input is not a valid comparison.
A profile shows where observed time or calls accumulate; it does not automatically identify which code is wasteful. A hot function may perform necessary work, be invoked too often or wait on an external resource. Inspect the call path and data size before changing it.
Report the workload boundary and trade-offs rather than turning a local result into a universal claim.
What this chapter covers
- 01
A performance question with a named operation and metric
- 02
Representative inputs held constant across versions
- 03
Repeated baseline measurements and visible variability
- 04
Profiles that rank cost by function or operation
- 05
Call relationships that explain repeated work
- 06
Correctness parity before accepting a speed result
- 07
Time, memory and complexity trade-offs
- 08
Measured claims limited to the tested workload
Worked example · free
Remove repeated parsing from one report
- +1Preserve the exact directory, command, environment and baseline output.
- +1Repeat the baseline to observe timing variability rather than relying on one run.
- +1Confirm from the profile that repeated parsing is a dominant cost.
- +1Parse and validate records once, then supply that population to each aggregation.
- +1Compare structured results or output bytes to prove correctness parity.
- +1Repeat candidate measurements under comparable conditions.
- +1Report the measured distribution and memory or complexity trade-off within the tested workload.
Key terms
- Workload
- The defined operation and input used for measurement. It should represent the use whose performance matters.
- Baseline
- Repeated measurements of the current implementation under recorded conditions, used as the comparison for a candidate change.
- Profile
- Observed resource data showing where a workload spends time or calls. It suggests mechanisms but does not by itself judge necessity.
- Hotspot
- A location responsible for a substantial share of measured cost in the defined workload. It may be necessary or avoidably repeated.
- Correctness parity
- Evidence that baseline and candidate implementations satisfy the same output and error contract before performance is compared.
- Benchmark variability
- Natural movement between runs caused by caches, scheduling, start-up and other environment factors that must be acknowledged.
Profiling and Performance FAQ
Why should I profile before optimising?
The apparent slow line may contribute little to total time. A profile locates dominant measured cost and helps estimate whether a proposed change can materially affect the complete workload.
Why are repeated measurements necessary?
Caches, process start-up and background load cause timing variation even when code is unchanged. Repetition reveals the distribution and prevents one unusually favourable run from becoming the conclusion.
Can a faster result still be wrong?
Yes. A candidate may skip records, suppress diagnostics or change ordering. Establish correctness parity with assertions or output comparison before treating a lower time as an improvement.
How should I report a performance improvement?
Name the workload, environment, metric, repeated baseline, repeated candidate, correctness check and relevant trade-offs. Limit the claim to those tested conditions instead of promising universal speed.
Assessment move
Choose one command whose output can be checked exactly. Define a fixed input and record the environment, then run it repeatedly to see ordinary timing variation. Profile the workload and write down the top costs with their call relationships. Select one mechanism that can plausibly affect total time, predict the expected observation and make a bounded change. Compare outputs before comparing timings.
Repeat measurements and summarise the distribution, not only the best result. Next vary input size and observe whether memory or elapsed time scales differently. Revert an experiment that adds complexity without a measured benefit and record what hypothesis it refuted. Practise critiquing flawed claims such as comparing different inputs, showing one run or omitting correctness.
The objective is to treat performance as an evidence problem rather than a code-aesthetics contest. Repeat the comparison with cold and warm filesystem conditions, treating each condition consistently across versions. Check exit status and diagnostics in addition to result bytes so a candidate cannot appear faster by suppressing work.
End with a bounded claim that names the workload and trade-off, then ask which different input would most likely challenge the conclusion.
Working through Profiling and Performance in FIT2109? Sia is AskSia’s AI Computer Science tutor — ask any FIT2109 Profiling and Performance question and get a clear, step-by-step explanation grounded in how FIT2109 is taught and assessed. Read this chapter free, then take your hardest questions to Sia.
