Runtime & concurrency
Reveal answer and reasoning
Define representative inputs and independently expected results before timing either implementation. Choose the operation scope, build configuration, runtime, architecture, and whether setup or allocation costs belong in the question. Use an appropriate Release benchmark without a debugger, consume the results, retain multiple observations, and use a proper benchmarking tool when its isolation and analysis capabilities are needed.
Record timer units and allocation scope, avoid treating current-thread counters as cross-thread async totals, and keep each target environment labeled separately. The wrong plan compares repeated calls to the same function, calls stable output equivalence, and then generalizes one tiny Debug duration to every deployment. Verify the known arithmetic result separately from repeatability; the external workload's sum of zero through ninety-nine is four thousand nine hundred fifty.
Report what was actually measured and what remains an untested hypothesis rather than filling those gaps with preferred numbers.
What a strong answer covers
- Use independent correctness before measurement.
- Control scope, configuration, result consumption, and samples.
- Keep environment and counter limitations attached to conclusions.
Common pitfall
Using self-consistency as the only oracle and one Debug measurement as a cross-runtime speed guarantee.
Follow-up questions
- When should setup be measured separately?
- How would you compare browser and desktop results honestly?
Self-review
Choose what to revisit. These marks are your own assessment and are separate from lesson completion.