16 Measure-First Optimization

16.1 Start With One Measured Bottleneck

Change One Energy Cost and Measure Again

Picture a battery sensor that dies early even after its code was made faster. Firmware means the software stored on the device that controls sensing, sleep, radio use, and recovery.

Duty cycle means the share of time a device spends active instead of resting. Name that share, current in each mode, time in each mode, radio retries, and required service life. Measure the baseline, change one suspected cost, then repeat normal, weak-link, and restart cases.

Keep traces, settings, version, energy total, and any reliability change. This proves one change improved one measured budget, not every device goal; the deeper sections compare bottlenecks, trade-offs, constraints, and verification.

Optimization without evidence is guesswork. A firmware loop may look inefficient while the real energy loss is a radio retry, a voltage regulator, or a sensor warm-up delay.

This chapter keeps optimization grounded: measure first, choose the dimension that matters, change one lever, and verify that the full device budget improved.

Phoebe’s Field Notes: Where the V-Squared in P = alpha C V^2 f Actually Comes From

The mathematical gist. A switched node pays $CV^2$ joules per charge-discharge cycle, so changing a rail from 1.0 V to 1.3 V multiplies dynamic energy by $(1.3/1.0)^2=1.69$. The chapter’s 1.20 mA-s baseline therefore becomes 2.028 mA-s, while a 15 pF node rises from 15.0 pJ to 25.35 pJ per cycle.

Math Bridge · guided foundationsWhy does a small voltage rise cost so much switching energy?Let Battery Bruno derive the square law and test the chapter's 1.69× result. Learn the maths

16.2 Optimization Fundamentals

Optimization changes a system so it uses fewer resources or meets a tighter requirement. In IoT, that usually means one or more of these outcomes:

• lower total energy per useful result
• lower peak power or thermal stress
• shorter response time
• smaller flash, RAM, or data transfer footprint
• better reliability under the same resource budget

The difficult part is that these goals interact. Faster code may use more memory. Smaller code may take longer. Lower peak power may increase execution time. A good optimization process makes those trade-offs explicit before changing firmware, hardware, protocol behavior, or sampling policy.

16.3 Learning Objectives

By the end of this chapter, you will be able to:

• Explain the difference between speed, size, power, and energy optimization.
• Use measurement evidence to identify the real bottleneck.
• Estimate whether an optimization can materially improve the whole system.
• Compare candidate optimizations with a trade-off ledger.
• Define stop conditions and regression checks before changing code or hardware.
• Build a validation record that proves the optimization helped without breaking the product.

16.4 Four Optimization Dimensions

Most IoT optimization decisions can be described with four dimensions.

Use the labelled path in Figure 16.1 to challenge four optimization dimensions. If Speed cannot be connected to latency trace, the surrounding conclusion is premature.

Rather than treating the labels as a list, relate Speed to latency trace in Figure 16.1. The former adds a distinct review condition; the latter adds a distinct review condition. Size then adds a distinct review condition, completing the visual statement: No-panel diagram showing speed, size, power, and energy as four optimization dimensions connected to latency traces, build size, current traces, and duty-cycle evidence. That completed statement informs four optimization dimensions.

The same change can improve one dimension while harming another. For example, caching a lookup result may reduce CPU time but use more RAM. Compressing a packet may reduce radio airtime but add compute time. Deep sleep may lower average energy but add wake latency. The right choice depends on the product target and measured workload.

Checkpoint: Name The Target Dimension

• You now know why speed, size, power, and energy are different optimization targets.
• You now know that a single change can improve one dimension while harming another.
• You now know to tie the choice to the product target and measured workload.

16.9 Why Energy Becomes the Constraint

Device count does not automatically make an IoT system more valuable. A fleet that adds sensors faster than it adds trustworthy decisions can flatten out: each new device brings battery service, credential rotation, firmware updates, privacy review, support load, and failure modes. The desired curve is different. More devices and services should make the system’s decisions more useful without letting security, privacy, energy, or management cost grow faster than the benefit.

That is why optimization starts with measurement. It is not enough to say that a future processor will be faster or a future battery will be better. Compute density has historically improved much faster than battery energy density, and small devices are often limited by how much heat they can remove. The gap is not a vague impression — semiconductor logic has tracked something close to Moore’s law, roughly doubling every two years, while battery energy density has improved on the order of 5-8 percent a year, doubling closer to once a decade. A processor generation can leapfrog its predecessor before a comparable battery generation ships, which is why a design that assumes “the next chip will just be more efficient” is gambling on the wrong curve. A desktop processor can dissipate tens or hundreds of watts with a heat sink and fan. A phone may have only about a watt of comfortable thermal headroom. A wearable sensor may live in the uW-mW range, where an always-on radio, LED, regulator, or debug bridge can dominate the budget.

Power density creates another limit. As features shrink, the same chip area can try to do more work, but the heat has to leave through a package, enclosure, skin surface, or nearby air. When power density approaches uncomfortable or unsafe levels, the design response is not simply “clock it higher.” It is to reduce voltage where possible, use lower-power states, choose efficient peripherals, batch or avoid work, and verify the result on the whole device. The optimization record should therefore name the physical limit as well as the software change.

For IoT, the practical conclusion is direct: value, privacy, support, and energy are coupled. A change that saves 5 ms of CPU time but forces a radio retry, raises sleep current, increases support tickets, or exposes more household behavior may reduce the product’s real value. A defensible optimization proves that the full system improves, not only that one number moved.

16.10 Power, Energy, And Switching Reality

Power and energy are related, but they answer different review questions. Power is the instantaneous rate of energy use. It sets heat, regulator, and capacity limits. Energy is power accumulated over time. It sets battery life, operating cost, and whether a task that looks low-power actually consumed more total charge because it ran for longer. For a transactional workload, throughput and average power may dominate the review. For a non-transactional job, completion time and total energy may matter more.

The comparison with biological systems is a useful warning, not a product requirement. A human brain performs an enormous amount of distributed work on roughly 20 W, and a widely cited estimate puts its synaptic switching cost near 2 femtojoules per operation. A low-power Cortex-M0-class microcontroller running near its efficiency sweet spot, around 9 uA/MHz at 1.5 V with roughly one instruction per cycle, lands closer to 13 picojoules per operation — on the order of 6,000 times less efficient than the biological comparison. The lesson for IoT design is not to copy biology literally. It is to avoid wasting transitions, moving data, and keeping support systems awake when the useful work is small.

Energy proportionality is the missing property in many systems. A device at 30 percent utilization should ideally consume close to 30 percent of peak power, but real boards often keep regulators, clocks, memories, displays, radios, fans, or DC-DC converters partly on. That creates poor efficiency at low utilization, which is exactly where sensor gateways, intermittent edge nodes, and standby hubs spend much of their lives. The current trace should therefore include peripherals, processing, communication interfaces, physical I/O, chargers, and storage, not only the CPU core.

At the chip level, CMOS logic gives a concrete model for that trace. Dynamic power is switching power: a node changes state, charges or discharges capacitance, and pays an energy cost. A common review shorthand is P_switch = alpha * C * V^2 * f, where alpha is the activity factor, C is switched capacitance, V is supply voltage, and f is frequency. Static power is leakage: current that flows even when useful switching is not happening, and it often rises as features, operating temperature, and always-on domains become harder to control.

That model turns “optimize power” into specific levers. Lowering voltage can reduce dynamic power sharply, but frequency and voltage are coupled by timing limits, so DVFS needs a measured break-even point rather than a slogan. Reducing activity means disabling inactive clocks, gating unused data paths, batching work, and encoding buses so fewer bits toggle. Reducing capacitance means avoiding oversized drivers, long traces, unnecessary external buses, and layouts that switch more metal than the workload needs. Each lever belongs in the same evidence loop: state the workload, measure before, change one thing, and prove total energy, thermal margin, and correctness improved together.

Leakage power gives the static side its own levers. Process choices such as silicon on insulator can reduce substrate leakage. Architecture choices can use fewer transistors in the always-on path. Circuit choices can use slower or higher-threshold devices where timing slack allows it, because faster devices are often larger and leak more. Those are not firmware toggles after the board ships, but they are valid selection and review criteria when a device family is being chosen for a long-life endpoint.

Power gating is the runtime version of that idea: cut the virtual supply to an unused core, cache slice, floating-point unit, decoder, memory bank, or peripheral island instead of merely stopping its clock. Processor examples can show tens-of-times leakage reduction when a domain moves from active to shut-off, but that number is not free energy. The review must include wake latency, inrush and rail settling, retained or rebuilt state, thermal-sensor availability, cache or memory reinitialization, and the workload rule that decides when the component is idle long enough to shut down. A cool block in an infrared image is useful evidence only if the product still meets its response and recovery requirements.

Checkpoint: Include The Whole Device

• You now know why a 5 ms CPU saving is not enough evidence by itself.
• You now know to include radios, regulators, memories, displays, chargers, storage, and sleep states in the trace.
• You now know power gating must repay wake latency, inrush, rail settling, and state recovery.

16.11 Measurement-First Loop

Optimization should be treated as a controlled loop, not a collection of tricks.

The next measurement-first loop claim rests on a relationship, not an isolated value. Inspect Target and define a measurable in Figure 16.2 before accepting it.

First isolate Target on the figure at Figure 16.2; it defines what the design promises. Next pair define a measurable (adds a distinct review condition) with stop condition (adds a distinct review condition). Their pairing demonstrates that cyclic optimization loop through target, profile, select the bottleneck, change, verify, and re-profile, one change per pass. This is what the chapter needs before continuing measurement-first loop.

16.12 Bottlenecks And Limits

A bottleneck is the part of the system that dominates the resource you care about. If a function consumes most of the active time, a speed optimization there may matter. If sleep current dominates the energy budget, rewriting a fast function may not change battery life.

Treat the map at Figure 16.3 as the evidence boundary for bottlenecks and limits. Its Dominant and Secondary labels identify the conditions that must be checked together.

The evidence changes character across the diagram at Figure 16.3: Dominant adds a distinct review condition, Secondary adds a distinct review condition, then Minor adds a distinct review condition. The transition explains the caption’s core point — bar comparison of dominant, secondary, and minor contributors to a measured budget, with notes on hidden contributors and the Amdahl limit on whole-system gain. That point is the next premise in bottlenecks and limits.

A useful mental model is Amdahl-style reasoning:

$whole\ improvement\ is\ limited\ by\ the\ fraction\ you\ actually\ improve$

If a task is only a small part of the measured cycle, making it dramatically faster may barely change the total. If a state dominates the current trace, a modest improvement there can matter more than a dramatic improvement elsewhere.

16.13 Trade-Off Ledger

Use a ledger before committing to a change. The goal is not to predict everything perfectly; it is to make risk visible and measurable.

16.14 Decision Gates

Before applying a change, ask whether it passes these gates.

If a candidate fails one of these gates, it may still be a useful idea, but it is not ready to be treated as an optimization.

16.19 Worked Review: Duty-Cycled Sensor

Consider a duty-cycled sensor node with three measured contributors in each reporting cycle:

The best first optimization is not necessarily the most interesting code change. It is the change that moves the measured whole-system budget while preserving the product requirement.

16.20 Review Checklist

Before marking an optimization complete, confirm:

• The target requirement is stated in measurable terms.
• The baseline measurement covers the full relevant cycle.
• The selected change addresses a measured bottleneck.
• The trade-off ledger includes speed, size, power, energy, and reliability effects.
• Correctness tests still pass after the change.
• The after measurement uses the same workload and environment as the baseline.
• The improvement remains meaningful after considering wake time, retries, storage, and protocol overhead.
• The optimization record says when to keep, revise, or roll back the change.

Checkpoint: Keep Or Roll Back

• You now know the process order: target, profile, select, change, verify, and re-profile.
• You now know why the bottleneck gate comes before the favorite technique.
• You now know a result is complete only when the before/after record and regression checks agree.

16.21 Knowledge Check

16.22 Knowledge Check: Bottleneck First

16.23 Knowledge Check: Trade-Off Choice

16.24 Match Optimization Item To Purpose

16.25 Order The Optimization Process

16.26 Label The Optimization Record

16.27 Power Is A Rate; Energy Is The Bill

Optimization for battery life hinges on keeping power and energy distinct. Power is the instantaneous rate of consumption, measured in watts or, at a fixed voltage, in milliamps. Energy is power accumulated over time, measured in joules or milliamp-hours, and it is energy that drains the battery. A design can draw more power yet use less energy, if it finishes its work faster and returns to a low-power sleep sooner.

That idea is called race-to-sleep. Running a fixed amount of work at a higher clock draws more current while it runs, but it runs for less time, and crucially it pays any fixed active overhead - peripherals, regulators, a powered sensor - for a shorter interval before sleeping. Whether racing wins depends on how big that fixed overhead is and on whether going faster forces a higher voltage.

A quick charge check makes the distinction concrete. If mode A draws 12 mA for 20 ms, the active charge is 12 x 0.020 = 0.240 mA-s. If mode B draws only 6 mA but needs 70 ms, it spends 6 x 0.070 = 0.420 mA-s. The lower-current mode costs 0.180 mA-s more per report. At one report each minute, that gap is 259.2 mA-s per day, or about 0.072 mAh before sleep leakage, radio retries, and sensor warm-up are even counted.

Use that question before accepting any benchmark result. A fast result that leaves the radio waiting, keeps a sensor biased, or prevents the regulator from entering its lowest state is not an energy optimization yet. The measurement window must include the return-to-sleep path, because that is where many apparent firmware wins disappear.

16.28 Four Quantities To Keep Straight

16.29 Overview Knowledge Check

16.30 Race-To-Sleep Pays Off The Fixed Overhead

Model the active current as I_active = k x f + I_fixed, a frequency-proportional dynamic part plus a fixed overhead that is on whenever the core is awake. For a fixed workload of N cycles, run time is N / f, so the dynamic energy is constant with frequency while the fixed-overhead energy shrinks as the clock rises.

16.31 Worked Example: An 8 Million Cycle Task

Take k = 0.15 mA/MHz and a fixed overhead of 2 mA while awake, at a constant core voltage.

• At 16 MHz: run time 0.5 s; current 0.15 x 16 + 2 = 4.4 mA; energy 4.4 x 0.5 = 2.20 mA-s.
• At 48 MHz: run time 0.167 s; current 0.15 x 48 + 2 = 9.2 mA; energy 9.2 x 0.167 = 1.53 mA-s.
• Why: the dynamic charge is 1.2 mA-s at either clock (frequency cancels), but the fixed 2 mA overhead costs 1.0 mA-s at 16 MHz and only 0.33 mA-s at 48 MHz. Racing pays that overhead for a third of the time.

So the faster clock uses about 30% less energy despite drawing twice the current, entirely because the fixed active overhead was paid for less time - and only if the core actually sleeps once the task ends.

Do the same arithmetic with the costs around the task. If both choices pay a 0.25 mA-s wake transition, the totals become 2.45 and 1.78 mA-s, so the fast case still wins. If the fast case alone also pays a 0.70 mA-s voltage-switch or PLL-lock cost, its total rises to 2.23 mA-s, roughly equal to the slow baseline. That is why the ledger must include wake, clock, sensor, and regulator overheads, not just instruction time.

16.32 Race-To-Sleep Ledger

16.33 Practitioner Knowledge Check

16.34 Voltage Scaling Can Flip The Result

Race-to-sleep assumed the higher clock ran at the same voltage. Often it cannot. Dynamic power scales with the square of the supply voltage as well as with frequency, so if reaching a higher clock requires raising the core voltage, the dynamic energy that was previously constant now grows with voltage squared. A 20% voltage increase multiplies the dynamic energy by about 1.44, which can wipe out the fixed-overhead saving. In the worked example, the 1.2 mA-s dynamic part would become about 1.73 mA-s, pushing the 48 MHz total to roughly 2.06 mA-s - now barely better than the slow clock, and worse at larger voltage steps.

What must survive the move from Switching-power relationship to · V² · f? The visual at Figure 16.4 poses that question for the current voltage scaling can flip the result decision.

Begin with the · V² · f label in Figure 16.4, noting that it adds a distinct review condition. Look backward to Switching-power relationship, which exposes the energy consequence, and forward to Incomplete device-energy model, which exposes the energy consequence. This reveals why dVFS race-to-sleep decision showing how voltage and frequency change active power, execution time, active energy, and the break-even idle interval, with measured evidence required before choosing an operating point. The visual therefore advances voltage scaling can flip the result, rather than interrupting it.

For the same 8 Mcycle task, suppose the 48 MHz point needs the core voltage to rise from 1.0 V to 1.3 V. The dynamic term is multiplied by 1.3 x 1.3 = 1.69, so the 1.20 mA-s dynamic charge becomes about 2.03 mA-s. Add the 0.33 mA-s fixed overhead at the shorter run time and the fast case is 2.36 mA-s, worse than the 16 MHz baseline at 2.20 mA-s. The useful rule is to race within the constant-voltage band, then stop when voltage scaling crosses the measured break-even point.

That is why the energy-optimal frequency is often a middle value rather than the maximum. As long as you can raise frequency at constant voltage, race to the top and sleep. Once further speed demands more voltage, the square-law dynamic penalty eventually overtakes the linear time saving, and pushing faster costs more energy. Two other conditions must also hold: the device must return to a genuinely low sleep floor after finishing, and the wake and transition overhead must be small compared with the saving. Race-to-sleep is a real and useful strategy, but it is a claim to verify with the voltage curve and the sleep behavior, not a universal law.

16.35 When Racing Stops Winning

16.36 Under-the-Hood Knowledge Check

Use this check to distinguish a shorter execution time from lower task energy when the fastest operating point also requires a higher core voltage. Work through the evidence in three stages: identify whether frequency increased inside a constant-voltage band, determine whether the new performance state raised voltage, and compare measured charge for the complete task plus its return to sleep. A faster result is beneficial only when the reduced active duration outweighs the voltage-squared dynamic penalty, transition cost, and any change in the sleep floor. The answer should therefore follow the measured operating-point curve, not a universal “race faster” rule.

16.37 Summary

Optimization fundamentals are the discipline behind every later optimization technique:

1. Define the target before changing anything.
2. Measure the full cycle or workload.
3. Choose the measured bottleneck, not the most familiar technique.
4. Compare speed, size, power, energy, reliability, and support effects.
5. Change one scoped thing at a time.
6. Verify correctness and remeasure the whole system.
7. Keep the optimization only if the evidence proves it helped.

16.38 What’s Next

16.43 Key Takeaway

Optimization starts with a measured objective. Profile first, choose the bottleneck, preserve correctness, and verify that the change improves energy, latency, memory, or cost under the target workload.