Define optimization in the context of IoT systems and understand why it matters
Identify the four key optimization dimensions: speed, size, power, and energy
Analyze trade-offs between competing optimization goals
Select appropriate optimization priorities based on application requirements
Avoid common optimization mistakes including premature optimization
In 60 Seconds
IoT optimization balances four competing dimensions — speed, code size, power, and energy — and the first rule is always to measure before optimizing, since the bottleneck is almost never where you expect it; premature optimization of the wrong component wastes time while the real problem remains.
Key Concepts
Optimization Dimensions: Speed (execution time), size (flash/RAM footprint), power (peak current), and energy (total joules consumed) — each matters differently depending on the application
Premature Optimization: Optimizing code before profiling identifies the actual bottleneck; wastes effort and often introduces bugs in non-critical paths
Profiling: Measuring actual execution time and resource consumption to identify where a system spends most of its time or energy
Power vs Energy: Power is instantaneous rate (watts); energy is total consumption (joules) — reducing peak power does not necessarily reduce total energy if it extends execution time
Amdahl’s Law: The speedup from optimizing a portion P of a system is limited by (1-P); optimizing 50% of code can at best double overall performance
Trade-off Analysis: Systematic comparison of optimization options by impact on all four dimensions, since improving one often degrades another
MCU Peripheral Optimization: Selecting the right peripheral interface (SPI vs I2C vs UART) to minimize both latency and energy for data transfer
15.2 Prerequisites
Before diving into this chapter, you should be familiar with:
Sensor Fundamentals: Knowledge of sensor power consumption provides context for energy optimization
Sensor Squad: The Art of Doing More with Less!
“Optimization is about making your device do the same job but better,” explained Max the Microcontroller. “Maybe faster, maybe smaller, maybe using less power. But the first rule of optimization is: do NOT optimize before you measure! Find out what is actually slow or wasteful, then fix THAT, not what you assume is the problem.”
Sammy the Sensor described the four dimensions: “Speed means how fast you process data. Size means how much memory your code uses. Power means how much energy per second. And total energy means how long the battery lasts. You usually cannot optimize all four at once – making code faster often makes it bigger, and making it smaller often makes it slower.”
Lila the LED shared the biggest trap: “Premature optimization! That is when you spend hours making one tiny function 10 percent faster, when the real bottleneck is somewhere completely different. It is like polishing the doorknob while the roof is leaking.” Bella the Battery agreed, “Profile your code first, find the hot spots that use 80 percent of the time or energy, and optimize THOSE. Leave the rest alone!”
For Beginners: What is Hardware and Software Optimization?
Think of optimization like packing a suitcase for a long trip—you want to fit the most important items while keeping the bag light.
In IoT, your “suitcase” is limited: tiny memory, slow processors, and batteries that need to last years. Optimization is the art of making your code and hardware do more with less.
Two types of optimization:
Type
What You’re Improving
Example
Hardware
Energy, power, heat
Make sensor sleep more, transmit less
Software
Speed, memory
Use smaller data types, avoid loops
Why optimization matters in IoT:
Resource
Desktop Computer
IoT Device
RAM
16 GB
256 KB (65,000x less!)
CPU
3 GHz
80 MHz (40x slower)
Power
500 watts
0.001 watts
Battery
N/A
Must last 5+ years
Common optimization techniques:
Loop unrolling — Instead of looping 100 times, write out 4 iterations at once (faster, but bigger code)
Function inlining — Put tiny function code directly where it’s called (saves overhead)
Fixed-point math — Use integers instead of decimals (much faster on small processors)
Sleep modes — Put the chip to sleep between readings (saves battery)
The trade-off triangle:
Speed
/\
/ \
/ \
/______\
Size Power
You can optimize for two, but often sacrifice the third!
Real-world example:
Original code: Reads sensor every 1 second, always awake -> Battery lasts 2 days
Optimized: Reads every 10 seconds, sleeps between readings -> Battery lasts 6 months!
Key insight: In IoT, “good enough” code that runs for years beats “perfect” code that drains the battery in a week.
Interactive: IoT Design Trade-off Simulator
15.3 What is Optimisation?
Time: ~10 min | Level: Intermediate | Unit: P13.C13.U01
Optimisation: Modifying some aspect of a system to make it run more efficiently or use fewer resources.
Optimising Hardware: Making it use less energy, or dissipate less power
Optimising Software: Making it run faster, or use less memory
15.3.1 Key Optimization Techniques
The following visualizations illustrate essential optimization techniques for IoT system development.
Avoiding Branch Delay
Figure 15.1: Branch delay avoidance uses conditional moves instead of if-else branches to prevent pipeline stalls. This optimization eliminates 5-15 cycle penalties on processors with deep pipelines, particularly effective for simple conditional assignments in tight loops.
Function Inlining
Figure 15.2: Function inlining eliminates call overhead by embedding small function bodies directly at the call site. This visualization compares the assembly output before and after inlining, showing how 5-10 cycle call overhead is eliminated for frequently-invoked helper functions.
Exploiting Parallelism
Figure 15.3: Modern microcontrollers support SIMD (Single Instruction, Multiple Data) operations for parallel processing. This visualization shows how loop iterations can be vectorized to process 4 elements simultaneously, achieving near-linear speedup for array operations.
Low-Overhead Programming
Figure 15.4: Minimizing overhead is critical for responsive IoT firmware. This visualization presents low-overhead programming patterns including hardware timer-driven scheduling, DMA transfers, and zero-copy buffer management that reduce CPU cycles per operation.
Hardware-Software Co-Design
Figure 15.5: Optimal IoT systems require co-design of hardware and software. This visualization shows the iterative process of matching firmware algorithms to hardware capabilities, identifying bottlenecks, and refining both sides to achieve system-level performance targets.
15.4 Optimisation Choices
Figure 15.6: IoT Optimization Trade-offs: Speed, Size, Power, and Energy Constraints
Alternative View: Optimization Priority by Application
This view helps select optimization priorities based on your specific IoT application:
Your application type determines which optimization trade-offs make sense.
Key Questions:
Optimise for speed? Do we need to react to events quickly?
Optimise for size? Are we memory/space constrained?
Optimise for power? Is there limited scope for power dissipation?
Optimise for energy? Do we need to conserve as much energy as possible?
Usually requires some combination (with trade-off) of all of these!
Cross-Hub Connections
This chapter connects hardware and software optimization to several learning resources:
Interactive Explorations:
Simulations Hub - Power Budget Calculator (line 35) helps quantify battery life improvements from optimization strategies. Compare baseline vs optimized: e.g., sensor duty cycle 1s -> 10s with sleep modes can extend 2-day battery to 6+ months
Knowledge Map - Navigate relationships between optimization techniques, compiler flags, and hardware accelerators across the IoT stack
Assessment & Practice:
Quizzes Hub - Test understanding of compiler optimization flags (-O0/-O2/-O3/-Os), fixed-point arithmetic (Qn.m format), and vectorization (SIMD) performance calculations
Knowledge Gaps Hub - Common optimization misconceptions explained: premature optimization, ignoring algorithmic complexity, and misunderstanding energy vs speed trade-offs
Video Resources:
Videos Hub - Visual explanations of ARM big.LITTLE architecture, SIMD vectorization benefits (4x throughput), and fixed-point vs floating-point performance comparisons with real hardware demonstrations
Why These Connections Matter: Hardware-software co-optimization requires quantitative analysis. The Simulations Hub provides calculators to measure actual energy/performance trade-offs (e.g., -Os saves 32 KB flash but adds 3ms latency—is it worth it for a duty-cycled sensor?). The Knowledge Gaps Hub addresses the #1 mistake: optimizing before profiling. Use the interactive tools to validate optimization decisions with data, not assumptions.
Common Misconception: “Faster Code Always Uses Less Power”
The Misconception: Many developers believe that optimizing for speed (-O3 compiler flag, aggressive loop unrolling, SIMD vectorization) automatically reduces power consumption because the processor finishes work faster and can sleep sooner. This leads to choosing speed-focused optimizations for battery-powered IoT devices.
Why It’s Wrong (With Numbers): Power consumption = Voltage^2 x Capacitance x Frequency. Faster code often requires: - Higher clock frequency (80 MHz -> 200 MHz = 2.5x power for 2x speed) - More parallel execution units (SIMD uses 4x ALUs = 3x power draw during execution) - Larger code size (-O3 generates 1.5-2x more instructions = more instruction fetches = more memory power)
Real-World Example: Consider a temperature sensor reading every 10 seconds: - Baseline (-O2): 18ms processing @ 80 MHz, sleep 9,982ms -> Average power: 5 mW active + 0.01 mW sleep = 0.019 mW average - Speed Optimized (-O3 + 200 MHz): 6ms processing @ 200 MHz (12 mW active), sleep 9,994ms -> Average power: 12 mW active + 0.01 mW sleep = 0.017 mW average - Size/Energy Optimized (-Os + sleep): 22ms processing @ 80 MHz, sleep 9,978ms -> Average power: 5 mW active + 0.01 mW sleep = 0.020 mW average
The Surprise: Speed optimization saved only 10% power (0.019 -> 0.017 mW) because sleep time dominates (99.8% of cycle time). The 12ms time savings (18ms -> 6ms) is irrelevant when sleeping 9,982ms! Meanwhile, -O3’s larger code size increased flash memory by 38% (52 KB -> 72 KB), requiring more expensive hardware.
The Correct Approach: For duty-cycled IoT devices, optimize sleep time, not active time: - Sleep deeper: Change sleep mode from 10 uA to 1 uA = 10x power savings (far exceeds any -O3 benefit) - Sleep longer: Reduce sensor sampling rate 1s -> 10s = 10x battery life (if application permits) - Optimize for size: Use -Os to minimize flash/RAM -> enables cheaper MCUs with smaller batteries
When Speed DOES Save Power: Speed optimization helps when the device cannot sleep during processing: - Real-time audio/video processing (continuous operation) - Safety-critical systems (must respond within deadline) - Compute-bound tasks preventing sleep (e.g., cryptography taking >1 second)
Key Principle from Chapter: “Optimise for energy? Do we need to conserve as much energy as possible?” For battery-powered IoT, the answer is optimize for longest sleep time, not fastest execution. The chapter shows: flash memory dominates die area (27.3 mm^2 vs 0.43 mm^2 for CPU)—choosing -Os over -O3 saves both energy AND cost by enabling smaller flash chips.
Quantitative Decision Rule: If sleep time > 100x active time, optimize for code size/sleep depth. If active time > 10% of cycle time, then consider speed optimization. For typical IoT sensors (0.1-1% duty cycle), speed optimization provides <1% battery life improvement.
15.4.1 Interactive Calculator: Speed vs Energy Trade-off
Show code
viewof active_time_base = Inputs.range([1,100], {value:18,step:1,label:"Baseline active time (ms)"})viewof active_power_base = Inputs.range([1,20], {value:5,step:0.5,label:"Baseline active power (mW)"})viewof sleep_power = Inputs.range([0.001,1], {value:0.01,step:0.001,label:"Sleep power (mW)"})viewof cycle_time = Inputs.range([1,60], {value:10,step:1,label:"Cycle interval (seconds)"})viewof speed_factor = Inputs.range([1.5,4], {value:3,step:0.1,label:"Speed optimization factor (x faster)"})viewof speed_power_mult = Inputs.range([1,3], {value:2.4,step:0.1,label:"Speed power multiplier (x more power)"})
Key Insight: Adjust the duty cycle slider to see when speed optimization matters. For typical IoT sensors with <1% duty cycle (active time << sleep time), speed optimization provides negligible battery life improvement.
Premature Optimization Wastes Development Time
A classic mistake is optimizing code before measuring where bottlenecks actually are. Developers spend days hand-optimizing assembly or complex bit manipulations in functions that consume 0.1% of total execution time, while ignoring the inefficient algorithm consuming 80% of CPU. Example: A team spent 2 weeks optimizing sensor reading code (saving 5ms per hour) but never profiled their JSON parsing library that consumed 2 seconds per message. Rule: Always profile first - use actual measurements to identify hotspots. The 80-20 rule applies: 80% of execution time typically comes from 20% of code. Focus optimization efforts on measured bottlenecks, not assumptions. Start with algorithmic improvements (O(n^2) to O(n log n)), then compiler flags, then micro-optimizations only if needed.
Tradeoff: Active Power Gating vs Continuous Low-Power Peripherals
Option A (Active Power Gating): MOSFET switch cuts power to sensors/peripherals when idle, achieves true zero leakage (<0.1 uA), requires GPIO pin + MOSFET ($0.05-0.20), adds 1-10 ms startup delay for sensor stabilization, potential for inrush current damage if not managed
Option B (Continuous Low-Power Mode): Peripherals remain powered but in ultra-low-power standby, typical standby current 1-50 uA per peripheral, instant readiness (<1 us), no external components, stable sensor calibration maintained
Decision Factors: Choose power gating for sensors with high standby current (>100 uA) or rarely used peripherals (GPS module at 20 mA idle - gate it!), deployments where every microamp matters for 10+ year battery life. Choose continuous low-power for frequently accessed sensors (accelerometer at 6 uA standby, sampled 10x/second - gating overhead exceeds savings), temperature-sensitive sensors requiring thermal stabilization (10-second warmup wastes more energy than continuous 5 uA), or when GPIO pins are scarce. Quantified example: A humidity sensor drawing 50 uA standby, read every 60 seconds: Continuous = 50 uA x 60s = 3 mAs/cycle. Power-gated = 0 uA x 59s + 2mA x 500ms warmup = 1 mAs/cycle - 3x better. But for 1-second reads: Continuous = 0.05 mAs, Power-gated = 1 mAs - continuous wins by 20x.
Tradeoff: Compiler Size Optimization (-Os) vs Speed Optimization (-O3)
Option A (-Os Size Optimization): Minimizes code size (20-40% smaller than -O3), moderate compile time, fits in smaller/cheaper flash (32 KB vs 64 KB saves $0.30-1.00/unit), reduced instruction cache misses, slightly slower execution (10-30% vs -O3), better for I/O-bound code
Option B (-O3 Speed Optimization): Maximum execution speed through aggressive inlining and loop unrolling, larger code size (1.5-2x vs -Os), may exceed flash capacity on small MCUs, faster compile-intensive algorithms, risk of code size exceeding instruction cache causing performance regression
Decision Factors: Choose -Os for flash-constrained MCUs (STM32L0 with 32KB, ATtiny with 8KB), battery-powered devices where code fetches from flash cost energy (1-5 pJ/bit), networking/protocol stacks where code size dominates, and production cost optimization at scale (10K units x $0.50 flash savings = $5,000). Choose -O3 for compute-intensive DSP/ML on edge (audio processing, anomaly detection), latency-critical control loops (motor control, PID), and devices with abundant flash (ESP32 with 4MB). Quantified example: A 45 KB -O3 binary vs 28 KB -Os binary - the -Os version fits in a 32 KB STM32L011 ($0.80) instead of requiring 64 KB STM32L031 ($1.30), saving $0.50/unit at 15% performance cost. For 50,000 units, that’s $25,000 saved - worth the 3ms extra processing time per sensor read.
Scenario: Your battery-powered IoT sensor has 128 KB flash (80% full after -O2 compile) and runs on a 16 MHz ARM Cortex-M0+ processor. Current firmware processes sensor data in 45ms, transmits results via LoRaWAN (200ms), then sleeps for 10 minutes. You’re evaluating -O3 (code increases to 110 KB, processing drops to 30ms) vs. -Os (code shrinks to 65 KB, processing increases to 55ms).
Think about:
Which optimization flag should you choose and why?
How much does the 15ms processing time difference (45ms -> 30ms with -O3) affect battery life?
What’s the real benefit of reclaiming 25 KB flash with -Os?
Key Insight: Choose -Os. The 15ms processing time improvement from -O3 is irrelevant for battery life—the sensor sleeps 10 minutes (600,000ms) between readings. Active time is 45ms + 200ms = 245ms per cycle. Reducing to 30ms + 200ms = 230ms saves only 15ms/600,000ms = 0.0025% energy savings—negligible. Meanwhile, -Os frees 25 KB flash (128 KB -> 103 KB = 20% reduction), enabling: (1) future firmware updates, (2) data buffering during network outages, (3) additional features without hardware redesign. For duty-cycled IoT devices, code size matters more than processing speed when active time is tiny compared to sleep time. Exception: If processing exceeded 10 minutes, preventing timely readings, then -O3’s speed would matter. The chapter’s guidance: “Optimise for energy? Do we need to conserve as much energy as possible?”—here, sleep time dominates, so optimize for flash (future flexibility).
15.6 Worked Example: Optimizing a Smart Agriculture Sensor from 14-Day to 18-Month Battery Life
Scenario: A vineyard deploys 200 soil moisture sensors across 50 hectares. Each sensor uses an ESP32-S2 with a capacitive soil moisture probe, BME280 temperature/humidity sensor, and LoRa radio (SX1276). The initial firmware drains 2x AA batteries (3,000 mAh at 3V) in 14 days. The target is 18 months (547 days) – a 39x improvement. No hardware changes allowed.
Step 1: Profile the Baseline (Measure Before Optimizing)
Operation
Current Draw
Duration
Energy per Cycle
% of Total
ESP32-S2 active (Wi-Fi scanning at boot)
120 mA
3.2 s
384 mAs
42.7%
Soil moisture reading (ADC)
45 mA
800 ms
36 mAs
4.0%
BME280 reading (I2C)
48 mA
350 ms
16.8 mAs
1.9%
JSON formatting + logging
40 mA
1.5 s
60 mAs
6.7%
LoRa TX (14 dBm)
85 mA
1.8 s
153 mAs
17.0%
LoRa RX window
28 mA
5.0 s
140 mAs
15.6%
Serial debug output
42 mA
2.1 s
88.2 mAs
9.8%
Sleep (light sleep, Wi-Fi on)
5 mA
582.2 s
2,911 mAs
–
Total per 10-min cycle
597 s
3,789 mAs
Critical finding: Wi-Fi scanning at boot consumes 42.7% of active energy – but this sensor uses LoRa, not Wi-Fi. The Wi-Fi radio initializes automatically because the default ESP-IDF sdkconfig enables it.
Battery capacity: 3,000 mAh = 10,800,000 mAs
Baseline:
Cycles per day: 144 (every 10 min)
Energy per day: 144 × 3,789 = 545,616 mAs
Battery life: 10,800,000 / 545,616 = 19.8 days
Optimized:
Cycles per day: 48 (every 30 min)
Energy per day: 48 × 174.2 = 8,362 mAs
Battery life: 10,800,000 / 8,362 = 1,292 days = 3.5 years
Improvement: 65x (exceeded 39x target)
Putting Numbers to It
Let’s calculate the impact of each optimization step on average current draw:
Baseline average current (10-minute = 600s cycles): \[I_{\text{avg\_baseline}} = \frac{3789 \text{ mAs}}{600 \text{ s}} = 6.315 \text{ mA}\]
After deep sleep optimization (eliminated 2,901 mAs sleep contribution): - New sleep energy: \(0.01 \text{ mA} \times 582.2 \text{ s} = 5.822 \text{ mAs}\) - Total cycle energy: \(3789 - 2911 + 5.822 = 883.822 \text{ mAs}\)\[I_{\text{avg\_deepsleep}} = \frac{883.822 \text{ mAs}}{600 \text{ s}} = 1.473 \text{ mA}\]Improvement: \((6.315 - 1.473) / 6.315 = 76.7\%\) reduction from deep sleep alone!
Interval extension (10min→30min): \(\frac{2}{3}\) reduction in cycle frequency = \(66.7\%\) of remaining energy
Total improvement: \[\text{Factor} = \frac{6.315 \text{ mA}}{0.0968 \text{ mA}} = 65.2\times \text{ battery life extension}\]
This demonstrates that sleep mode optimization and sampling interval adjustments deliver exponentially larger benefits than code-level micro-optimizations.
15.6.1 Interactive Calculator: Battery Life Optimization
Show code
viewof battery_capacity = Inputs.range([1000,5000], {value:3000,step:100,label:"Battery capacity (mAh)"})viewof active_energy = Inputs.range([100,1000], {value:878,step:10,label:"Active energy per cycle (mAs)"})viewof sleep_current = Inputs.range([0.001,10], {value:5,step:0.1,label:"Sleep current (mA)"})viewof sleep_duration = Inputs.range([10,1800], {value:582,step:10,label:"Sleep duration per cycle (seconds)"})viewof cycle_interval = Inputs.range([60,1800], {value:600,step:60,label:"Cycle interval (seconds)"})
html`<div style="background: var(--bs-light, #f8f9fa); padding: 1rem; border-radius: 8px; border-left: 4px solid #16A085; margin-top: 0.5rem;"><h4 style="margin-top:0; color: #2C3E50;">Energy Breakdown per Cycle</h4><table style="width:100%; border-collapse:collapse; margin-bottom:1rem;"><tr> <td style="padding:8px; border:1px solid #ddd;"><strong>Active energy</strong></td> <td style="padding:8px; border:1px solid #ddd; text-align:right;">${active_energy} mAs (${battery_calcs.active_pct.toFixed(1)}%)</td></tr><tr> <td style="padding:8px; border:1px solid #ddd;"><strong>Sleep energy</strong></td> <td style="padding:8px; border:1px solid #ddd; text-align:right;">${battery_calcs.sleep_energy.toFixed(1)} mAs (${battery_calcs.sleep_pct.toFixed(1)}%)</td></tr><tr style="background: #E8F5F1; font-weight: bold;"> <td style="padding:8px; border:1px solid #ddd;">Total per cycle</td> <td style="padding:8px; border:1px solid #ddd; text-align:right;">${battery_calcs.total_cycle_energy.toFixed(1)} mAs</td></tr></table><h4 style="color: #2C3E50;">Battery Life Projection</h4><table style="width:100%; border-collapse:collapse;"><tr> <td style="padding:8px; border:1px solid #ddd;"><strong>Average current draw</strong></td> <td style="padding:8px; border:1px solid #ddd; text-align:right;">${battery_calcs.avg_current.toFixed(3)} mA</td></tr><tr> <td style="padding:8px; border:1px solid #ddd;"><strong>Cycles per day</strong></td> <td style="padding:8px; border:1px solid #ddd; text-align:right;">${battery_calcs.cycles_per_day.toFixed(1)}</td></tr><tr style="background: #16A085; color: white; font-weight: bold; font-size: 1.1em;"> <td style="padding:12px; border:1px solid #ddd;">Battery Life</td> <td style="padding:12px; border:1px solid #ddd; text-align:right;">${battery_calcs.battery_life_days.toFixed(0)} days (${(battery_calcs.battery_life_days/365).toFixed(1)} years)</td></tr></table><p style="margin-top:1rem; padding:8px; background: ${battery_calcs.sleep_pct>50?'#E67E22':'#16A085'}; color: white; border-radius:4px;">${battery_calcs.sleep_pct>50?'⚠️ Sleep energy dominates ('+ battery_calcs.sleep_pct.toFixed(0) +'%) - optimize sleep mode for maximum battery life improvement!':'✓ Active energy optimized - sleep consumes only '+ battery_calcs.sleep_pct.toFixed(0) +'% of energy.'}</p></div>`
Experiment: Try reducing sleep current from 5 mA to 0.01 mA (deep sleep mode) to see the dramatic battery life improvement. Then try extending the cycle interval to see how sampling frequency affects battery life.
Key lessons from this example:
Profile first: Wi-Fi initialization was the single largest energy consumer, yet it served no purpose. Without profiling, the team would have optimized LoRa TX (the obvious suspect) for minimal gain.
Sleep mode dominates: Switching from light sleep (5 mA) to deep sleep (10 uA) saved more energy than all other optimizations combined.
Remove, don’t optimize: Disabling unused Wi-Fi and serial debug together saved 52.5% – these are complete removals, not optimizations.
Sampling interval is the multiplier: Changing from 10-min to 30-min intervals reduced total energy by 3x. For soil moisture (which changes over hours, not minutes), 30-minute sampling loses no meaningful data.
Cost impact: At $3.50 per battery change (batteries + technician time per sensor), 200 sensors changed every 14 days = $18,200/year. At 3.5-year battery life, annual cost drops to $200/year – saving $18,000/year from firmware-only changes.
Matching Quiz: Match Optimization Dimensions to Trade-offs
Ordering Quiz: Order the Optimization Decision Process
Label the Diagram
💻 Code Challenge
Order the Steps
Match the Concepts
15.7 Summary
Optimization fundamentals establish the foundation for efficient IoT systems:
Four Dimensions: Speed, size, power, and energy often conflict—you must prioritize
Application-Driven: Industrial control needs speed; environmental sensors need energy efficiency
Avoid Premature Optimization: Profile first, optimize the actual bottleneck
Trade-off Analysis: Quantify benefits before choosing optimization strategies
Sleep Dominates: For duty-cycled devices, sleep efficiency matters more than processing speed
The key is understanding your application requirements and choosing appropriate optimization strategies with full awareness of trade-offs.
15.8 Knowledge Check
Quiz: Optimization Fundamentals
15.9 Concept Relationships
Optimization fundamentals establish the decision framework for all subsequent optimization work:
Measured By: All optimization decisions validated with Energy Measurement—profile before optimizing, measure after
Constrains: Energy budget from Energy-Aware Design determines which dimension to optimize (5-year battery → optimize for energy, not speed)
Contrasts With: Desktop optimization priorities (minimize latency) vs IoT priorities (maximize battery life)—different goals require different techniques
Core principle: Optimization is multidimensional—improving one dimension (speed) often degrades another (size, power). Framework helps navigate trade-offs systematically.
Optimization without a specific goal (e.g., “must fit in 256 KB flash” or “must last 2 years on a 2,000 mAh battery”) has no stopping condition. Define measurable targets before starting, and stop when they are met.
2. Confusing Power and Energy
A device that runs faster (higher power) but finishes sooner may use less total energy than a slower, lower-power device. Always calculate total energy (power × time), not just peak power, when evaluating battery life impact.
3. Applying the Same Optimization Strategy to All Devices
A latency-critical alarm sensor needs speed optimization; a once-per-hour environment monitor needs energy optimization. Applying speed optimization to the latter wastes development time and may increase energy consumption.
4. Not Re-profiling After Optimization
After applying an optimization, the bottleneck shifts. What was second-most expensive becomes the new bottleneck. Always re-profile after each optimization round to ensure continued effort targets the new critical path.
15.11 What’s Next
If you want to…
Read this
Explore processor selection and hardware acceleration
