Performance is how efficiently an application does its work. For a latency-sensitive application, a central question is how long an operation takes. Lower latency can improve user experience, meet real-time requirements, and increase efficiency. The practical route to improvement is to measure, find the bottleneck, and remove work that does not need to happen. section 1.3 section 7.1
Start with application logic: it is often controllable and can offer larger gains than changes to the runtime or operating system. Algorithmic complexity describes how time or space requirements grow with input size; time complexity gives a rough expectation of latency growth, not a measured duration. For instance, scanning an array is O(n) in the worst case, while a hash-table lookup averages O(1) but can be O(n) in the worst case. section 7.1 section 7.2
A measurement-led workflow is:
- Identify a frequently used path and benchmark it before changing its implementation. section 7.7
- Check for repeated computation and other work in application logic, serialization, deserialization, and memory management; use profiling to locate where time goes. section 7.1 section 7.7
- Change the implementation, then benchmark again. Consider runtime and operating-system work too, but do not assume the most visible code is the bottleneck. section 7.1 section 7.0
Measuring Fibonacci implementations
A recursive Fibonacci function recalculates earlier values and has exponential time complexity. A Criterion microbenchmark of its tenth value measured roughly 157.71 ns. Memoization stores earlier results and measured roughly 44.21 ns; an iterative version measured roughly 5.07 ns. These figures compare implementations for that benchmarked input, rather than establishing their latency across an entire application. Run the benchmark with cargo bench and use CPU profiling when a timing result alone does not reveal where work occurs. section 7.7
$ cargo bench fibonacci/recursive time: [157.39 ns 157.71 ns 158.06 ns] Found 10 outliers among 100 measurements (10.00%) 7 (7.00%) high mild 3 (3.00%) high severe fibonacci/memoization time: [43.891 ns 44.208 ns 44.637 ns] Found 6 outliers among 100 measurements (6.00%) 4 (4.00%) high mild 2 (2.00%) high severe fibonacci/iterative time: [5.0518 ns 5.0690 ns 5.0888 ns] Found 6 outliers among 100 measurements (6.00%) 4 (4.00%) high mild 2 (2.00%) high severe
The benchmark output places the recursive, memoized, and iterative timings side by side, including measurement ranges and outliers. section 7.7
