As energy costs rise and concerns about environment increases, developers are beginning to realize that optimizing for performance isn’t enough — it’s time to optimize for sustainability. Most of the small, distributed devices running inefficient software can collectively waste significant power and increase the global carbon footprint.

While performance profiling has always been the primary concern for developers, energy profiling has often been overlooked, especially across the diverse layers of the IoT ecosystem.

“Energy efficiency is not just about saving power, it’s about designing smarter.” — Dr. Amory Lovins

Yet, when developers try to measure this energy impact, they quickly hit a wall: there simply aren’t enough profiling tools that work across all layers of IoT architecture — from device firmware to cloud applications.

🌐 The Multi-Layered Reality of IoT

An IoT system isn’t a monolith. It’s a stack of layers, each performing distinct functions and using different technologies:

IoT Software Stack Layers
Layer Description
Device Layer Sensors, microcontrollers, and embedded software — highly constrained in power and memory.
Network Layer Responsible for connectivity, data routing, and transmission between devices.
Edge Layer Gateways that preprocess, aggregate, and analyze data before sending it to the cloud.
Cloud / Processing Layer Backend servers that handle storage, computation, and analytics.
Application Layer User-facing software — dashboards, APIs, and control applications.

Each layer has its own languages, profiling tools, and performance challenges.
However, energy efficiency — the thread tying them all together — is treated inconsistently across this stack.

🧩 The Fragmented Profiling Landscape

Here’s what the current ecosystem looks like for performance and energy profiling tools across IoT layers:

IoT Layer C/C++ C# Java JavaScript Python
Device Layer gprof — — — —
Network Layer — — — — —
Wireshark, tcpdump (protocol-level)
Edge Layer perf, PowerJoular — JoularJX Clinic.js, Oaklean PyJoules
Cloud/Processing Layer perf, PowerJoular dotTrace, PowerJoular JProfiler, JoularJX Node.js Profiler, Oaklean cProfile, CodeCarbon
Application Layer perf, CPPJoules PerfView JProfiler, YourKit, JoularJX Node.js Profiler, Oaklean PyInstrument, PyJoules

🧾 Key Observations:

  • Energy profiling availability lags far behind performance profiling across all layers and languages.
  • The Device and Network layer still lacks necessary tools for both, performance tracking and energy analysis.
  • C# has no dedicated energy profiling tools despite having strong performance profilers (dotTrace, PerfView).
  • JavaScript energy monitoring tools are experimental (Oaklean at multiple layers, Clinic.js at Edge layer)
  • Tools like Wireshark and tcpdump help us observe data flow, but they don’t tell us how much energy that flow costs.

As the table reveals, today’s profiling ecosystem is fragmented. For example, while cloud and application layers have mature tools like JProfiler, YourKit, and CodeCarbon, network and device layers — remain largely uncharted when it comes to energy-aware profiling. The unavailability of the required tools across all IoT layers for most of the programming languages highlights the need for standardised profiling tools across languages and platforms.

Even if the tools for example, JProfiler and YourKit to measure execution time, memory use, and bottlenecks, or JoularJX to measure energy consumption of Java applications, they lack the way to correlate traditional performance metrics, like execution time and memory usage, with the energy consumption

Existing tools like JProfiler (for performance) and JoularJX (for energy) do a great job — but in isolation.
They report data separately, leaving developers with fragmented insights:

  • You can know a method consumes CPU time, but simultaneously not how much energy it draws.
  • You can measure total process energy — but not which specific (exactly overloaded) methods are responsible.
  • You can’t easily correlate performance bottlenecks with energy inefficiencies.
“If you can’t measure it, you can’t improve it.” — Peter Drucker

As a result, developers make optimization decisions that might improve speed but increase energy use — an invisible trade-off in most existing profiling setups.

🌱 SPECTRA: Bridging the Profiling Divide

That’s where SPECTRA comes in.
SPECTRA — short for Software Performance, Energy Consumption, Time, and Resources Analysis — is a unified framework that captures, merges, and correlates performance and energy metrics in one place.

Initially developed as SPECTRA-J for Java-based IoT applications, it:

  • is built on top of JoularJX and JProfiler to collect synchronized data
  • Correlates execution time, invocation count, and energy usage at the method level
  • Distinguishes overloaded methods with identical names but different parameters
  • Generates unified analytical reports Spreadseets friendly reports for developers to interpret directly

SPECTRA transforms fragmented metrics into actionable insights, helping developers see not just how fast their code runs — but how green it runs.

Without data, you’re just another person with an opinion. — W. Edwards Deming

The vision is to extend SPECTRA across all IoT layers and languages, including: SPECTRA-C/C++, SPECTRA-C#, SPECTRA-JS, and SPECTRA-Python

SPECTRA began with a simple realization — we can’t optimize what we can’t see. By bridging performance profiling with real energy data, it transforms how developers perceive code efficiency. Every method call, every millisecond, every joule — all now part of the same conversation.

By making energy efficiency a first-class metric, SPECTRA helps developers build software that’s not just powerful — but planet-friendly.

Because the future of software engineering isn’t just about writing faster code — it’s about writing smarter, cleaner, and greener code. SPECTRA is our small step toward that future. 🌱

References:

[1] Déaglán Connolly Bree and Mel Ó Cinnéide. 2025. How Software
Design Affects Energy Performance: A Systematic Literature Review. J. Softw.
Evol. Process 37, 4 (March 2025), 25 pages. doi:10.1002/smr.70014


[2] Nadine Amsel and Bill Tomlinson. 2010. Green tracker: a tool for estimating the energy consumption of software. In CHI ’10 Extended Abstracts on Human
Factors in Computing Systems (Atlanta, Georgia, USA) (CHI EA ’10). Association
for Computing Machinery, New York, NY, USA, 3337–3342. doi:10.1145/1753846.1753981


[3] Sruthy Anand and Maneesha Vinodini Ramesh. 2021. Multi-Layer Architecture
and Routing for Internet of Everything (IoE) in Smart Cities. In 2021 Sixth International Conference on Wireless Communications, Signal Processing and Networking (WiSPNET). 411–416. doi:10.1109/WiSPNET51692.2021.9419428


[4] Silvio Barra, Ferdinando D’Alessandro, and Oleksandr Sosovskyy. 2024. Exploring Architectural Choices and Emerging Challenges in Data Management for IoT: A Focus on Digital Innovation and Smart Cities. In Adjunct Proceedings of the 32nd ACM Conference on User Modeling, Adaptation and Personalization (Cagliari, Italy) (UMAP Adjunct ’24). Association for Computing Machinery, New York, NY, USA, 429–436. doi:10.1145/3631700.3665238


[5] Aurélien Bourdon, Adel Noureddine, Romain Rouvoy, and Lionel Seinturier. 2013. PowerAPI: A Software Library to Monitor the Energy Consumed at the Process- Level. ERCIM News 92 (Jan. 2013), 43–44. https://inria.hal.science/hal-00772454

[6] Nitin Singh Chauhan and Ashutosh Saxena. 2013. A Green Software Development
Life Cycle for Cloud Computing. IT Professional 15, 01 (Jan. 2013), 28–34. doi:10.
1109/MITP.2013.6