Runtime & concurrency
Reveal answer and reasoning
Choose a representative workload with an independent correctness oracle and record SDK, runtime, architecture, build configuration, debugger state, and relevant runtime settings. Compare controlled configurations in separate appropriately launched processes, keeping startup and repeated-operation questions distinct. Use Release where an optimized-code comparison is intended, and gather diagnostics that can identify actual method code generation rather than assuming a call count names a tier.
Retain multiple measured observations and validate equivalent work before drawing conclusions. Capability flags can describe the environment, while timers describe the selected scope; neither replaces method-specific evidence. The wrong plan chooses one tiny duration, repeats until a preferred number appears, and labels it Tier1. An interpreter or AOT target may need a different question entirely. Report exactly which artifacts and runtime behaviors were observed, and keep any unexecuted configuration or native publication clearly outside the claimed test scope.
What a strong answer covers
- Record environment and independent correctness first.
- Separate startup, steady-state, and code-generation evidence.
- Use measured observations rather than invented durations.
Common pitfall
Assigning a JIT-tier explanation to timing differences without observing the method's generated code.
Follow-up questions
- How would you prevent dead-code elimination?
- How would the experiment differ for a browser interpreter?
Self-review
Choose what to revisit. These marks are your own assessment and are separate from lesson completion.