# Local Computing vs. Cloud Computing: An Empirical Study of Energy Consumption

Lylian Siffre, Thomas Ledoux, Renaud Pawlak, John Guery

► To cite this version:

Lylian Siffre, Thomas Ledoux, Renaud Pawlak, John Guery. Local Computing vs. Cloud Computing: An Empirical Study of Energy Consumption. IEEE/ACM 18th International Conference on Utility and Cloud Computing, Dec 2025, Nantes, France. pp.1-10, 10.1145/3773274.3774278 . hal-05324506

HAL Id: hal-05324506

https://hal.science/hal-05324506v1

Submitted on 21 Oct 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>
# Local Computing vs. Cloud Computing: An Empirical Study of Energy Consumption

Lylian Siffre

lylian.siffre@imt-atlantique.fr
lylian.siffre@kapela.fr
IMT Atlantique, Inria, LS2N
Nantes, France
Kapela
Paris, France

Renaud Pawlak

renaud.pawlak@localflow.fr
LocalFlow
Paris, France

## Abstract

The dominance of Software-as-a-Service (SaaS) has raised sustainability concerns due to its reliance on centralized cloud infrastructure and increasing energy consumption. This paper investigates a core principle of the Local-First Software (LoFi) paradigm, local processing, as a potential alternative. Through a controlled empirical study using SeekTune, an open-source music recognition application, we compare the end-user device and server energy consumption and data usage of a local processing architecture against a traditional SaaS model for a computationally intensive task. Our results demonstrate that, while local processing consumes more energy on the client device, the combined energy cost of data transmission and server-side computation in the SaaS model often results in a larger total systemic footprint. For modern mobile devices, processing locally can be significantly more energy-efficient overall. These findings challenge the long-held assumption that cloud offloading is inherently superior, and position the local processing aspect of LoFi as a crucial consideration for sustainable software design.

## CCS Concepts

* Hardware → Impact on the environment; * Computer systems organization → Distributed architectures; * General and reference → Empirical studies.

## Keywords

Local-First Software, Cloud-Computing, Energy Consumption

## 1 Introduction

The proliferation of Software-as-a-Service (SaaS) has established a dominant paradigm for application delivery, valued for its scalability and manageability [18]. However, this centralized model introduces significant concerns beyond vendor lock-in and data privacy [10]; it is also intrinsically linked to the increasing energy footprint of the Information and Communications Technology (ICT) sector, which is now a critical concern in sustainable computing research [9, 15].

Thomas Ledoux

thomas.ledoux@imt-atlantique.fr
IMT Atlantique, Inria, LS2N
Nantes, France

John Guery

john.guery@kapela.fr
Kapela
Paris, France

This energy challenge necessitates a critical re-evaluation of default architectural patterns. The long-standing assumption that offloading computation to the cloud is inherently more efficient is now being undermined by two key technological trends. First, the sustained exponential improvement in the energy efficiency of end-user hardware, as historically observed by Koomey's Law, has dramatically increased the computational capacity available on consumer devices [11, 17]. Second, the maturation of the software stack such as WebAssembly (WASM) provides a high-performance, energy-efficient compilation target for Web browsers, enabling client-side execution that rivals native performance and significantly outperforms interpreted languages like JavaScript [16, 24].

These advancements suggest a viable alternative: moving back the software on the end-user device. The critical trade-off is no longer purely about computational throughput, but must account for the total systemic energy cost. This includes the energy consumed by data center servers for remote computation, plus the energy expended by the client device to power its network interface for data transmission and wait for the response. From the sustainability perspective, we posit that for a significant class of applications, this revised computation may favor an emerging paradigm: Local-First Software [20].

Local-First Software (LoFi) is a software paradigm first formally defined by Kleppmann et al. [10] through a set of seven ideals, including offline operation, data ownership, and multi-device synchronization. At its core, LoFi represents a fundamental architectural shift from the SaaS model. While SaaS centralizes data storage and computation in the cloud, LoFi repositions the user's local device as the primary place for both data ownership and processing. This prioritization of locality is the key enabler for its defining characteristics: resilience to network failures, inherent user sovereignty over data, and the ability to collaborate asynchronously [21]. LoFi represents a complete architectural shift; hence, our study will focus on one specific aspect: local processing (LP) of computationally intensive tasks (e.g., OCR, data search, or media transcoding; general-purpose workloads excluding hyperscale, HPC applications, or requiring specialized hardware).

While the energy efficiency of individual components like WASM is established, a rigorous empirical comparison of the end-user
device plus server energy consumption of a SaaS architecture versus a local processing equivalent is absent from the literature. This paper addresses this gap by presenting a controlled empirical study that quantitatively measures and compares these two architectural paradigms.

Through a controlled empirical study of a computation-intensive application, we instrument both client and server sides to measure key environmental metrics: energy consumption and data transmission volume. Our methodology executes the application on a range of modern mobile devices to capture hardware heterogeneity. The results demonstrate that the local processing architecture can yield a substantial reduction in the application's recurring operational footprint. This work provides a data-driven foundational argument for rethinking computation offloading strategies and contributes a methodological framework for evaluating the energy efficiency of software architectures.

This paper is organised as follows: Section 2 reviews related work on mobile computation offloading and its device-centric energy focus. Section 3 details our methodology for the controlled empirical study, including the design of the testbed and the demonstration app. Section 4 presents the findings from our measurements of energy and data consumption across the end-user devices and servers. Section 5 interprets the implications of these results for efficient software architecture. Section 6 discusses threats to validity. Section 7 concludes and outlines future work.

## 2 Related Work

The challenge of optimizing energy consumption in mobile software has evolved in tandem with the computing paradigms designed to support it. The initial shift from centralized Cloud Computing (CC) to Mobile Cloud Computing (MCC) promised to alleviate the computational burden on resource-constrained devices by leveraging powerful cloud infrastructure [14]. This was later followed by the advent of Mobile Edge Computing (MEC), which aimed to further reduce latency and potentially improve energy efficiency by deploying computational resources at the network edge, closer to the end-user [2, 19]. A central and persistent problem within these paradigms is the offloading decision, determining the optimal execution venue (local device or remote server) to minimize a target metric, often energy consumption. Although early work established this as a fundamental challenge [5], the literature has historically prioritized optimizing the battery life of mobile devices [1].

Seminal systems like CloneCloud [5] pioneered this device-centric approach. It introduces a novel architecture where a virtual clone of a smartphone's execution environment runs in the cloud, enabling the fine-grained, thread-level migration of computation. A thread on the mobile device could be suspended, its state transferred to its cloud clone for execution, and the result returned to resume on the device. The explicit goal of CloneCloud and contemporaneous frameworks like MAUI [7] and ThinkAir [12] is to overcome the hardware limitations of mobile devices to extend battery life and enhance application performance. This establishes a clear optimization objective: minimizing the energy consumption of the mobile device itself. For instance, subsequent work formulated an

energy-optimal task migration scheme for CloneCloud using a genetic algorithm, but its cost function is defined exclusively from the perspective of the mobile device's energy savings [13].

This device-centric focus, while a rational design choice for its time, inherently limits the perspective of these foundational systems. Their models largely considered the energy consumption of data centers and network infrastructure as externalities outside their optimization scope. As evidenced by a recent survey [6], this approach remains common in the field, with most strategies prioritizing the mobile device's energy savings without evaluating the broader system-wide impact. This indicates that a more holistic analysis is needed, one that accounts for the combined energy consumption of the device, network, and server to fully assess the efficiency of modern mobile software architectures.

## 3 Experimental Methodology

All details about the experiments we conducted are gathered in this section. First, we define our research goal, questions, and metrics in Section 3.1. Then, Section 3.2 presents SeekTune, the software serving as our real-world example for this study. Section 3.3 and Section 3.4 present in-depth details about the setup and the scenarios for this study. Finally, Section 3.5 presents the artifacts for reproducing our experiments and downloading the dataset.

### 3.1 Research Goal, Questions and Metrics

This study evolves in the Goal-Question-Metric (GQM) Framework [22]. Although our process is iterative and agile in nature, where initial measurements inform refinements to our experimental setup, the GQM model provides the ideal framework for *ex post facto* justification and structuring of our research.

**Goal.** Benchmark energy and data efficiency of SaaS versus Local-Processing (LP) architectures for computationally intensive workloads on contemporary mobile devices, assessing how local computation compares to SaaS's historical energy advantages.

**Questions.** Based on the goal defined above, we formulate the following research questions:

(1) **RQ1:** What is the quantitative difference in resources consumption between the SaaS and LP versions for a set of core tasks?

(a) **RQ1.1:** In energy consumption?

(b) **RQ1.2:** In data transfer?

(2) **RQ2:** How is the difference in energy consumption affected by variations in network conditions?

**Metrics.** Our research questions are addressed through a two-tiered measurement approach, combining precise client-side mobile metrics with direct server-side power measurement.

(1) **M1 (Client): Energy Consumption per Task:** Total energy consumed by the mobile device to complete a defined core task, measured in Milliwatt-Hour (mWh). (measured via Android Debug Bridge [8]).

(2) **M2 (Client): Data Transferred:** Total number of bytes sent to and received from the network interface during a task, measured in Megabytes (MB). (measured via Android Debug Bridge [8]).

(3) **M3 (Client): Task Duration:** Total end-to-end time for the user to complete the task, measured in seconds (s).
(4) **M4 (Server): Energy per Request:** Direct power draw of the server node hosting the SaaS backend service and database, measured during request processing. Aggregated to **mWh per request**. (measured via Grid'5000 wattmeters directly with current clamps on the power cables<fnref n="1" />).

(5) **M5 (Server): Request Round-Trip Time (RTT):** Time elapsed between the client sending a request and receiving the full response, measured in **milliseconds (ms)**. (this includes server processing + network transit time).

## 3.2 SeekTune

To ground our empirical comparison in a real-world use case, we selected **SeekTune**<fnref n="2" />, an open-source music recognition application. Its core functionality mirrors that of commercial services like **Shazam**<fnref n="3" />: a user can record a short audio sample from their environment, and the application will attempt to identify the song.

**Local-Processing Version.** The canonical implementation of SeekTune follows an LP architecture. The computationally intensive step of generating a fingerprint from the raw audio sample is performed locally on the user's mobile device. This fingerprint is then sent to a remote server, whose sole responsibility is to compare it against a database to find a match and return candidate songs. By offloading only the lightweight fingerprint (rather than raw audio), this design minimizes data transfer per request.

**Modified SaaS Version.** For the purpose of this study, we engineered a modified SaaS version of SeekTune. In this variant, the recorded audio sample is immediately sent to a remote server. The server performs the computationally intensive tasks of fingerprinting and database matching, returning a list of candidate songs to the client. This client-server model shifts the computational burden away from the resource-constrained mobile device, but introduces a continuous dependency on network availability and quality.

**Adaptation for Instrumentation.** The original software version used the microphone to create the audio file. In our modified version of SeekTune, the client downloads an audio file from the server to be used as the recording. We changed this behavior to reduce the complexity and variability of the instrumentation.

**Fingerprint Generation.** For a fingerprint to be generated in SeekTune's implementation, the sample first undergoes preprocessing (converting stereo to mono, resampling the signal, and applying a Hamming window). The computationally intensive part of the fingerprinting is the Short-Time Fourier Transform (STFT). This algorithm processes the input by applying a FFT (Fast Fourier Transform) across a series of windows. The general complexity for an FFT of size *M* is $O(M \log M)$, and this operation is repeated for a number of windows proportional to the input length *L*. This would suggest a complexity of $O(L \cdot M \log M)$. However, in this implementation, the FFT size *freqBinSize* (*M*) and the hop size *hopSize* are fixed constants (1024 and 32, respectively). Therefore, the per-window FFT cost is constant, and the overall complexity of the STFT operation scales linearly with the input length, resulting in $O(L)$. Despite this linear complexity, the algorithm is not lightweight; the constant factors are large, and it can easily saturate an

<figure><img src="image_2.png" /><figcaption>**Figure 1:** Activity diagram for SeekTune. SaaS flow is in orange and Local Processing (LP) in green.</figcaption></figure>

end-user device's CPU if the sample is very long or if the operation is called repeatedly. This makes it a prime candidate for analyzing the energy trade-offs between local and remote computation.

**Code Implementation.** The code implementing the aforementioned fingerprinting algorithm is written in Golang for both variants of the software. Crucially, the core fingerprinting code is identical in both versions; the only differences lie in its compilation target and place of execution. The SaaS version runs as plain compiled Go code on a remote server. In contrast, the LP version is compiled to WASM and executed directly within the end-user's web browser. This distinction is crucial for our energy analysis, as it pits the energy cost of local computation (WASM in the browser) against the combined cost of network transmission and remote computation (server-side Go).

Figure 1 presents a high-level overview of the activities within the SeekTune SaaS and LP versions. In this figure, the implementation differences between SaaS and LP are represented by two different colors, orange and green, respectively.

## 3.3 Experimental Setup

To ensure our findings are based on representative and well-grounded data, our experimental setup is designed to capture all necessary

<footnote n="1">¹Installation details: https://slices-fr.gitlabpages.inria.fr/tech/docs/users-doc/docs/tutorials/precursors/grid5000/energy-monitoring/</footnote>

<footnote n="2">²https://github.com/cgzirim/seek-tune</footnote>

<footnote n="3">³https://www.shazam.com/</footnote>
metrics directly, avoiding reliance on estimation models where
possible.

**Server-Side Testbed: Grid’5000.** We conducted our server-side measurements using Grid’5000 (G5K) [3], a large-scale testbed providing “bare-metal as a service” for experimental research. A key feature of G5K is its fine-grained control over all infrastructure layers, including **integrated wattmeters** that provide high-precision monitoring of server energy consumption at the power cable level.

To evaluate the application’s performance under different hard-
ware conditions, we deployed it on two distinct clusters:

* **Chirop-4 (Lille, France):** High-performance nodes equipped with Intel Xeon Platinum 8358 CPUs<fnref n="4" />.

* **Orion-1 (Lyon, France):** Older nodes equipped with Intel Xeon E5-2630 CPUs, representing hardware approximately nine years older than the Chirop cluster<fnref n="5" />.

This selection allows us to stress-test both the SaaS and LP versions
across a spectrum of computational capabilities.

**Local-Processing Testbed: Greenspector.** For client-side mea-
surements on end-user devices, we utilized the Greenspector testbed<fnref n="6" />,
an industrial platform for profiling the energy consumption and
performance of mobile applications on real Android and iOS de-
vices. The testbed stabilizes [8] the battery of the device before
starting the experiment.

We conducted our experiments on a range of Android devices to
account for variability in hardware performance and age:

* Samsung Galaxy S22 - Released: **2022**, February 25

* Samsung Galaxy Tab S7 FE - Released: **2021**, June 18

* Samsung Galaxy S9 - Released: **2018**, March 09

* Samsung Galaxy S7 - Released: **2016**, March 11

These devices utilize various versions of the Android operating
system, as summarized in Figure 2. Our experimental setup relies
on Wi-Fi for all Internet communications.

<figure><img src="image_3.png" /><figcaption>Figure 2: Materials Overview.</figcaption></figure>

**3.4 Experimental Scenarios**

Figure 3 depicts the devices used for both scenarios. In this figure, the probed devices for both scenarios are highlighted with a grey background. The following paragraphs describe the scenarios.

<figure><img src="image_4.png" /><figcaption>Figure 3: Scenarios Setup Overview. Devices Scenario only probes the end-user device, and Servers Scenario only probes the application server.</figcaption></figure>

**Server.** The server scenario is a stress test. The stress test was conducted using Locust<sup>7</sup>, configured to start at 0 requests per second and gradually increase to 1000 requests per second. During the experiment, we monitored power consumption and API statistics, including requests per second and latency. To evaluate the energy efficiency of the two versions of the application (LP vs SaaS) across different CPU architectures, we conducted experiments under two power-management configurations. The technical details of our server instrumentation and deployment are provided in Section 3.5.

**End-User Device.** The end-user device scenario is the steps a user would take to open the application, and search for matches five times in a row. Figure 4 describes the steps’ order in the scenario; their meaning is described in Table 1. Our client instrumentation methodology, which ensures reproducible execution of user scenarios, is detailed in Section 3.5. The internal behavior of SeekTune at Step 4b is described in Figure 1.

<figure><img src="image_5.png" /><figcaption>Figure 4: User Scenario Steps Diagram.</figcaption></figure>

**3.5 Open and Reproducible Science**

In accordance with the imperative for reproducibility, we have
designed this study to be fully transparent and replicable. All com-
ponents of our experimental pipeline, from server provisioning to
mobile application testing, are automated using open technologies
and detailed in our artifacts.

**Server Instrumentation and Deployment.** The server-side infrastructure was deployed and configured using EnOSlib [4], a Python library designed for reproducible computational experiments on testbeds like Grid’5000. Our EnOSlib scripts explicitly

<footnote n="4">⁴https://www.grid5000.fr/w/Lille:Hardware#chirop</footnote>

<footnote n="5">⁵https://www.grid5000.fr/w/Lyon:Hardware#orion</footnote>

<footnote n="6">⁶https://greenspector.com/en/home/</footnote>

<footnote n="7">⁷https://github.com/locustio/locust</footnote>
<table><caption>Table 1: User Scenario Steps Description.</caption><thead><tr><th>Step ID</th><th>Description</th></tr></thead><tbody><tr><td>Start</td><td>Start of the GDSL Script</td></tr><tr><td>1</td><td>30s pause on a black tab in the browser</td></tr><tr><td>2</td><td>Opening the application</td></tr><tr><td>3</td><td>30s pause on the tab of the application</td></tr><tr><td>4a</td><td>5s pause before clicking the "Listen" button</td></tr><tr><td>4b</td><td>Wait for the process to finish</td></tr><tr><td>4c</td><td>10s pause after process finished</td></tr><tr><td>End</td><td>End of the GDSL Script</td></tr></tbody></table>

define the hardware specifications, software environment (e.g., dependencies), and deployment steps for all server nodes. This automation guarantees that any researcher can precisely recreate our experimental server setup, eliminating manual configuration errors.

**Client Instrumentation and Test Automation.** To ensure consistent and reproducible measurements on the mobile client, we automated all user interactions using the Greenspector Domain-Specific Language (GDSL) [8]. GDSL scripts define our core tasks as a precise sequence of actions (e.g., open app, click, press key, input text) and synchronization points (e.g., wait for 5 seconds, wait for text "Save" to appear). This approach eliminates inter-run variability caused by manual testing and provides a verifiable, executable record of exactly how each energy measurement was conducted.

**Artifact Availability and Replication Package.** In accordance with best practices for open science, we provide a complete replication package:

* **Source Code and Data:** All EnOSlib deployment scripts, GDSL test scenarios, analysis code, and the complete dataset are available in a persistent data repository: https://zenodo.org/records/17406175.

* **Detailed Documentation:** Our artifacts include a README.md with instructions for reproducing our entire experimental workflow, from provisioning nodes to generating the final figures.

# 4 Results

Following the definition of our RQs in Section 3.1, the results section will address all RQs, respectively.

## 4.1 RQ1.1. Quantitative difference in energy consumption between SaaS and LP versions

Figure 5 presents the total energy consumed (in mWh) by the client device during the 2nd through 5th iterations of Step 4b for the LP and SaaS versions. The two versions are represented by green and orange dots, respectively, LP and SaaS. The red squares indicate the total baseline energy consumption (estimated from Step 3), which constitutes the system overhead unrelated to the target activity. The activity diagram (Figure 1) illustrates that the initial iteration of Step 4b is a setup phase, during which the audio sample is downloaded and pre-processed. Data from this warm-up iteration is omitted from the final analysis.

<figure><img src="image_6.png" /><figcaption>Figure 5: On-device energy consumption for Step 4b across all devices and software versions.</figcaption></figure>

The measurements confirm that the LP implementation consumes significantly (one-tailed, paired-samples t-test yielded *p* = .046) more energy on the client device than the SaaS counterpart, which offloads the core processing. This result is expected, as the LP version handles all computations locally, while the SaaS version's role is reduced primarily to data transfer. Despite this fundamental difference, the time taken by the software versions is very close between the SaaS and LP versions across the devices. This analysis is to be put in perspective with the fact that the server, during the end-user device's experiment, has no load (i.e., it answers as fast as possible). So it is expected that in real conditions with load on the server, the user will have to wait longer on the SaaS version than on the LP version.

In addition, the data also reveal that modern system-on-a-chip designs substantially mitigate this energy overhead. As shown in Table 2, which aggregates the median energy consumption of each device, the performance gap narrowed considerably across device generations. The difference in median energy consumption between the two versions decreased from 1.694 mWh on the Samsung Galaxy S7 to 0.416 mWh on the Samsung Galaxy S22, corresponding to a 75.4% reduction in the LP energy penalty.

<table><caption>Table 2: Median End-user Device Energy Consumption for Step 4b.</caption><thead><tr><th>Phone Model</th><th>LP (mWh)</th><th>SaaS (mWh)</th></tr></thead><tbody><tr><td>Samsung - Galaxy S22</td><td>1.520</td><td>1.104</td></tr><tr><td>Samsung - Galaxy Tab S7 FE</td><td>1.365</td><td>1.205</td></tr><tr><td>Samsung - Galaxy S9</td><td>3.045</td><td>1.870</td></tr><tr><td>Samsung - Galaxy S7</td><td>4.581</td><td>2.887</td></tr></tbody></table>

This narrowing gap can be attributed to the generational improvements in general-purpose computational efficiency, including more advanced CPU architectures, smaller semiconductor process nodes, and superior power management. This trend suggests that
the energy cost of performing complex local computations (e.g., FFTs or OCR) is becoming less prohibitive.

## 4.2 RQ1.2. Quantitative difference in data transfer between SaaS and LP versions

Since all tests have slightly different durations, let us focus on tests 4 and 7 for best visibility. Figure 6 presents the cumulative data transfer for the complete user scenario. The bar plots show the total data transmitted for specific phases of the application's operation, while the line plots illustrate the evolution of cumulative consumption over time. The SaaS and LP versions are colored orange and green, respectively.

<figure><img src="image_7.png" /><figcaption>Figure 6: Evolution of cumulative data transfer throughout the user scenario (up to the first iteration of the Steps 4abc). The bar plots categorize consumption into three distinct behavioral phases (A, B, C).</figcaption></figure>

The data transfer is segmented into three categories, corresponding to different application behaviors:

(1) **Category A: Initial Application Payload.** This phase includes the download of the initial application code (Step 2), and the reference step (Step 3).

(2) **Category B: Audio Sample Download.** This corresponds to the initial download of the binary audio sample file, which occurs on the first iteration of Step 4b.

(3) **Category C: Core Fingerprinting Operation.** This category accounts for all data transmitted after the audio sample is pre-processed.

The comparison reveals the architectural trade-off:

* **Category A** is larger for the LP version. This is an expected and necessary cost of the paradigm, as the client must download the WASM code and APIs required to perform the audio fingerprinting locally. The SaaS version offloads this computational logic to the server, resulting in a smaller initial download.

* **Category B** is identical for both versions, as both require the same initial audio sample file.

* **Category C** demonstrates the decisive advantage of the LP version. Here, the SaaS version must transmit a pre-processed JSON representation of the audio sample (~3.5 MB) for server-side analysis. In contrast, the LP version transmits only the resulting audio fingerprint (~2 KB): a reduction in data volume by three orders of magnitude. It is noteworthy that the SaaS payload, while smaller than the original audio file (5.3 MB), is still significantly larger than the fingerprint.

## 4.3 RQ2. Effect of network conditions on energy consumption

A fundamental principle of cloud SaaS is resource mutualization to optimize efficiency. However, under high load, increased latency can trigger auto-scaling events. To understand the energy implications of this dynamic at scale, we developed a model to estimate total server power and energy-per-request for the SaaS version under increasing request throughput. This model is based on empirical data from stress tests performed on a single server instance. In the LP version, the sole non-local component is the database responsible for song matching. Since this component works identically and with high efficiency in both versions, it will be excluded from further consideration.

**Model Construction.** We first establish a baseline by stress-testing a single server node to its performance limit, defined by a latency threshold of 1 second (our arbitrary Service Level Agreement target). From this test, we record two key empirical relationships:

(1) The relationship between **throughput** (x, in req/s) and **server power draw** (P(x), in W), which we fit to a third-degree polynomial function.

(2) The maximum throughput a single server can handle while maintaining the latency threshold, denoted as $T_{max}$.

**Scaling Simulation.** We simulate a horizontal scaling policy where a new identical server instance is provisioned each time the total throughput X exceeds an integer multiple of $T_{max}$. The total power draw for a given throughput X is thus modeled as:

$$P_{total}(X) = P(T_{max}) \cdot \left\lfloor \frac{X}{T_{max}} \right\rfloor + P(X \text{ mod } T_{max})$$

The energy consumed per request is then:

$$E_{per-request}(X) = \frac{P_{total}(X)}{X}$$

**Results and Implications.** Figure 7 presents the output of our model, showing the estimated evolution of total server power draw and energy per request as throughput increases.

**Model Analysis and Asymptotic Behavior.** The model presented in the previous section is a purposeful simplification designed to isolate the first-order effects of scaling. A key property of this model is that the energy per request, $E(X)$, converges to a specific value.

**Theoretical Limit:** Given the structure of the model, we can derive the asymptotic behavior of $E(X)$ as the throughput $X$ grows infinitely large:

$$\lim_{X \to \infty} E(X) = \lim_{X \to \infty} \frac{P_{total}(X)}{X} = \frac{P(T_{max})}{T_{max}}$$
<figure><img src="image_8.png" /><figcaption>**Figure 7:** Simulated server power draw (orange, left axis) and energy consumed per request (grey, right axis) as a function of request throughput, based on an empirical model of single-server performance.</figcaption></figure>

According to our measurements, with $T_{max} \approx 146.7$ req/s and $P(T_{max}) \approx 651.7$ W watt, the theoretical lower bound for the energy cost of a single request is $E_{request-min} = \frac{651.7}{146.7} \approx 4.44$ J/req $\approx 1.22$ mWh/req. This result confirms that the simulated value of 1.22 mWh/req represents the fundamental lower bound for the energy cost of a single request within the constraints of our model.

However, this efficiency comes with a cost: latency. The latency forces the mobile device to remain in a high-power state while waiting for a response. The energy cost of this waiting (idle) period on the client is substantial and is incorporated into the final comparative analysis in Figure 8.

This figure reveals a critical and non-obvious finding that reframes the entire energy efficiency debate. The initial analysis (Figure 5) showed the raw computational cost where performing the task locally was significantly higher than the client-side cost of the SaaS approach. However, this comparison was incomplete as it ignored the systemic costs of offloading.

By incorporating the full-system energy costs, including the server-side energy per request, the trend reverses dramatically (one-sample t-test yielded $p = .006$). Consequently, for modern devices like the S22, the total energy of the LP version is now lower than the total energy of the SaaS version. This statistical reversal exposes the hidden energy burden of the SaaS model: the substantial cost of server-side computation, which is conveniently offloaded from the client device but not from the overall system.

<figure><img src="image_9.png" /><figcaption>**Figure 8:** Comparative analysis of energy consumption between LP and SaaS SeekTune for Step 4b.</figcaption></figure>

# 5 Discussion

In this section, we discuss the implications of our results for efficient software architecture. Section 5.1 discusses our SaaS energy model. Section 5.2 presents an intuition on how Local-First Software could reshape the energy efficiency debate. Finally, Section 5.3 exposes novel architecture ideas within the Local-First paradigm.

## 5.1 SaaS Best-Case Scenario

These results must be interpreted with the important caveat that our energy accounting for the SaaS model represents a best-case scenario. Our measurements capture the core server computation but intentionally omit significant additional costs inherent to real-world cloud deployment, including data center overhead (cooling, power distribution), operational infrastructure (load balancers, network switches), and the energy consumed by the vast intermediary network between the client and data center, and its quality (e.g., drop rate).

These factors are complex to attribute to a single request, but have an undeniable, positive aggregate impact. Consequently, the actual energy cost of a SaaS request is higher than our estimate, making our result a lower bound for its true cost. In contrast, the LP's cost is largely captured by our client-side measurement, as it minimizes reliance on this external infrastructure.

This framing critically reinforces our core conclusion: if the LP approach is competitive with or superior to a cloud-based approach even under these idealized conditions for SaaS, then its energy advantage in a typical deployment scenario is likely to be significantly more pronounced.

## 5.2 Architectural Sovereignty and Leveraging Heterogeneous Hardware

Our results highlight a systemic inefficiency of the prevailing SaaS model: it centralizes computation in data centers (Cloud and Edge) while failing to harness the vast, distributed potential of modern end-user hardware. This creates a paradox: data centers are tasked with operations that could be performed efficiently on the billions
of powerful devices in users’ pockets, which themselves remain
idle, acting as passive terminals.

The Local-First architecture enables a paradigm shift towards a
more balanced and resilient computational ecosystem. It leverages
the latest client hardware for efficient task execution, preventing
power drain and heat damage to old devices by retaining the server
and newer user devices (e.g., laptop) as a fallback, and enhances
user resilience and data sovereignty by reducing dependency on
continuous cloud connectivity.

Ultimately, our measurements suggest the energy cost of local computation on a modern device can be lower than the cost of cloud offloading. Thus, the key question evolves from “which hardware is more efficient?” to “which architecture best leverages the most efficient available hardware for a given task?”. A hybrid, task-oriented architecture that dynamically assigns work based on device capability and network condition emerges as the most energy-efficient and user-empowering path forward. This approach would also reduce server workload, allowing older devices to be repurposed and reducing the need for frequent upgrades - which, in turn, lowers the embodied greenhouse gas emissions of new hardware.

## 5.3 Towards Novel Local-First Architectures

Our results demonstrate the energy efficiency of leveraging local compute resources. This opens the door to novel software architectures that extend the Local-First paradigm beyond mere offloading, creating intelligent systems that actively exploit their distributed nature.

First, applications can leverage locality context to minimize energy consumption further. For instance, in our music recognition case study, a song played in a shared physical space is likely identifiable by other nearby devices. A Local-First architecture could use low-energy local network protocols like mDNS or Wi-Fi Direct to query a collaborative, ad-hoc network of devices before resorting to a more energy-costly server query. This transforms a collection of individual devices into a cooperative, energy-efficient sensing system.

Second, the paradigm enables energy-aware and delay-tolerant computation. By design, Local-First software remains functional without a continuous server connection. This allows non-urgent tasks to be queued and executed not just based on server load, but on external factors like the carbon intensity of the electricity grid. A provider could deploy modest, efficient hardware (e.g., a Raspberry Pi) to manage a request queue, dynamically provisioning cloud resources only when the queue length or a drop in grid carbon intensity justifies it. This moves beyond traditional scalability to achieve maximal resource and energy efficiency.

These speculative architectures illustrate that the Local-First paradigm’s potential extends far beyond replicating cloud functionality locally. It enables a fundamentally new class of applications that are context-aware, energy-adaptive, and leverage collective device resources, pushing the boundaries of green software engineering.

# 6 Threats to Validity

In this study, we attempt to empirically compare the end-user device and server energy consumption of SaaS and LP versions of

SeekTune. This research allows us to raise concerns about the commonly admitted fact that SaaS saves energy in most cases. In this Section, we present threats that challenge the validity of our results and how we try to mitigate them. We follow the categories from [23]: *conclusion validity*, *internal validity*, *construct validity* and *external validity*.

## 6.1 Conclusion Validity

This validity is concerned with threats to our ability to draw correct conclusions.

**Low Statistical Power.** A threat to conclusion validity is the limited number of runs (n=5) per experimental condition. A small sample size can reduce the statistical power of a study and increase its susceptibility to outliers. **Mitigation.** Despite the small sample size, a paired t-test performed on the results yielded a statistically significant p-value. This indicates that the observed difference in means is unlikely to have occurred by random chance alone.

**Reliability of Measures.** Another threat to conclusion validity is the reliability of measures. Energy measurement is often estimated or underestimates the real consumption of a system. **Mitigation.** All server-side measurements were taken with lab-grade equipment *multivoies* 2⁸ at the alimentation cable of the servers. End-user device’s energy consumption is determined via the current charge level of the battery given by ADB. It is important to note that this methodology captures energy consumption at the end-points (device battery and server PSU) but does not account for the energy consumed by the intermediate network infrastructure (routers, switches, etc.).

**Reliability of Treatment Implementation.** A threat to conclusion validity would be an underlying difference in the implementations of the fingerprinting algorithm itself, which could confound the results. **Mitigation.** This threat is mitigated by our experimental design. The algorithm is the same, in the same original language, but the only difference lies in the compilation target: it was compiled natively for the server-side SaaS version and to WebAssembly (WASM) for the client-side LP version. This ensures that the observed effects are due to the architectural shift and the performance characteristics of the execution environment (WASM vs. native), not due to algorithmic differences.

## 6.2 Internal Validity

This validity is concerned with the factors that may influence the dependent variable with respect to causality, without our knowledge.

**History.** A threat to internal validity due to the effect of timing of the experiment. **Mitigation.** As the discharge rate is not linear wrt the charge level, GSPT stabilizes the battery at a stable charge level before playing the scenario.

**Maturation.** A threat due to processes internal to the participants (or devices) that change over time. For example, the device's temperature increasing over successive runs due to computational load, potentially causing thermal throttling and altering performance/energy consumption. **Mitigation.** We enforced a mandatory cool-down period between experimental runs to allow the device to return to ambient temperature.

<footnote n="8">⁸See: https://www.adecwatts.fr/wattmetre-et-analyseur-de-reseau-bt/</footnote>
**Instrumentation.** A threat if the measurement instrument itself changes. For example, if the Android battery reporting API behaved differently between runs or Android versions. **Mitigation.** We used identical measurement procedures and software versions across all runs on a single device. All client-side measurements were taken using the same, well-established API.

**Selection.** A threat if the compared groups (in this case, the runs for SaaS and LP) are not equivalent at the start of the experiment. **Mitigation.** This threat is mitigated by our experimental design. We performed repeated measures, where the same physical device is used to test both architectures. This controls for all device-specific variables (hardware, OS version, background apps). The primary difference between test conditions is the software architecture itself.

**Implementation Fidelity.** A threat if the difference in results is caused by an unintended difference in the implementation quality of the two versions, rather than the architectural difference. **Mitigation.** As stated in the conclusion validity section, the core algorithm (the fingerprinting logic) is identical. The only intentional difference is the compilation target (native binary vs. WASM) and the network communication pattern. This ensures the treatment (the architectural shift) is implemented faithfully.

## 6.3 Construct Validity

This validity is concerned with whether our operational measures accurately reflect the theoretical constructs they are intended to represent.

**Inadequate Pre-operational Explication of Constructs.** Concerns a threat where the constructs are not well-defined. **Mitigation.** We thoroughly presented our methodology and provided our artifacts and datasets. In addition, our measurements concern energy, time, and data transmission; thus, they are obvious, making this threat minor for our study. However, a specific threat exists for the “total SaaS system energy” construct. Our model captures the core server computation and client energy but intentionally omits ancillary data center costs (cooling, power distribution, network infrastructure) which are difficult to attribute per-request. This means our measurement represents a best-case scenario for SaaS energy consumption, potentially strengthening our comparative finding that the Local-First architecture is more efficient. We explicitly acknowledge this simplification in the discussion.

**Mono-operation Bias.** A threat arising from using a single, narrow instance to represent a broader construct. Our study primarily investigates the construct of “architectural energy efficiency” through the lens of one specific task (audio fingerprinting). **Mitigation.** We acknowledge that audio fingerprinting, while computationally intensive, is just one type of task. The results may not fully generalize to the energy profile of other LoFi operations (e.g., conflict-resolution or synchronization). This choice was intentional to provide a clear, initial comparison of computational offloading vs. local execution. Future work is needed to extend this analysis to a wider range of tasks.

**Mono-Method Bias.** A threat from relying on a single method of measurement, which could introduce systematic error. **Mitigation.** For a given component, we used a single measurement method. While we used the best available methods for each environment, this is a limitation. We mitigated this by standardizing

our procedure (e.g., using GSPT to stabilize battery state) and using the same measurement method for both treatments on the same device, ensuring a fair comparison.

**Interaction of Testing and Treatment.** A threat where the act of measurement itself influences the outcome. **Mitigation.** The measurement tools are passive and do not interfere with the operation of the software under test. The experimental process itself (repeated runs) could cause device heating, but we mitigated this with cool-down periods and randomization, as noted in the internal validity threats.

## 6.4 External Validity

This validity is concerned with the extent to which the results of our study can be generalized beyond the specific experimental conditions to industrial practice and broader contexts.

**Interaction of Selection and Treatment.** A threat exists regarding the generalizability of our findings across different tasks, technological stacks, and hardware. Our experiment was conducted using a specific computationally intensive task (audio fingerprinting), implemented in a specific high-performance language (Go), and executed on a range of modern mobile devices. Consequently, the results may not be directly generalizable to less computationally intensive tasks (e.g., simple CRUD operations); tasks implemented in languages with different performance profiles or very old or low-performance end-user devices (more than 10 years old). **Mitigation.** The choice of a demanding task such as audio fingerprinting represents a critical case study; if the LoFi architecture proves to be more energy-efficient under this heavy load, it indicates its viability in a wide range of less demanding scenarios. Furthermore, by demonstrating the approach with Go, a language known for its efficiency, we establish a performance baseline. Future work can investigate trade-offs with other languages.

**Interaction of Setting and Treatment.** A threat arises from the potential difference between our experimental setting and real-world deployment. Our study was conducted in a controlled lab environment. **Mitigation.** We actively mitigated this threat by basing our experiment on SeekTune, a fully functional, non-trivial application. This demonstrates that implementing the LoFi architecture is a feasible, progressive enhancement for existing applications. The measured energy savings are thus a realistic estimate of the benefits achievable in practice for similar data-intensive applications.

## 7 Conclusions and Future Work

This paper presents a controlled empirical study comparing the energy and data consumption of the Software-as-a-Service (SaaS) and Local Processing (LP) versions of SeekTune, an open-source project, from the perspective of both servers and end-user devices.

Our findings challenge the prevailing assumption of SaaS's inherent superiority over traditional local processing. Across three critical domains, energy efficiency, data usage, and performance time, the LP approach demonstrates significant advantages, suggesting a need to re-evaluate the ecological and practical costs of modern cloud-centric paradigms. These results point toward novel architectural opportunities that blend the best of both approaches,
potentially giving rise to new hybrid architectural patterns for sus-
tainable computing that intelligently leverage both cloud and local
device resources.

This work provides actionable insights for practitioners seeking
to develop more sustainable software and establishes a foundation
on which researchers can build upon. Future work will explore
these hybrid Cloud+LP architectural patterns in depth. This in-
cludes expanding the empirical investigation to a wider range of
software types (e.g., collaborative text editors, compilers, or video
processing tools) and more realistic, variable server load condi-
tions to generalize these findings. A key goal is to formalize design
principles and decision frameworks for determining the optimal
distribution of computational workload between the client and the
server to minimize overall energy and data consumption.

Acknowledgments

This work was funded by Kapela and the ANRT through the CIFRE
program in partnership with Kapela. During the preparation of this
work, the authors used Deepseek V3.1 in order to: check grammar
and spelling, improve writing style. After using this tool/service,
the authors reviewed and edited the content as needed and take
full responsibility for the publication’s content.

References

[1] Saeid Abolfazli, Zohreh Sanaei, Abdullah Gani, Feng Xia, and Laurence T. Yang. 2014. Rich Mobile Applications: Genesis, taxonomy, and open issues. *Journal of Network and Computer Applications* 40 (2014), 345–362. doi:10.1016/j.jnca.2013.09.009

[2] Ehsan Ahvar, Anne-Cécile Orgerie, and Adrien Lebre. 2022. Estimating Energy Consumption of Cloud, Fog, and Edge Computing Infrastructures. *IEEE Transactions on Sustainable Computing* 7, 2 (April 2022), 277–288. doi:10.1109/TSUSC.2019.2905900

[3] Daniel Balouek, Alexandra Carpen Amarie, Ghislain Charrier, Frédéric Desprez, Emmanuel Jeannot, Emmanuel Jeanvoine, Adrien Lèbre, David Margery, Nicolas Niclausse, Lucas Nussbaum, Olivier Richard, Christian Perez, Flavien Quesnel, Cyril Rohr, and Luc Sarzyniec. 2013. Adding Virtualization Capabilities to the Grid’5000 Testbed. In *Cloud Computing and Services Science*, Ivan I. Ivanov, Marten van Sinderen, Frank Leymann, and Tony Shan (Eds.). Springer International Publishing, Cham, 3–20.

[4] Ronan-Alexandre Cherrueau, Marie Delavergne, Alexandre van Kempen, Adrien Lebre, Dimitri Pertin, Javier Rojas Balderrama, Anthony Simonet, and Matthieu Simonin. 2022. EnosLib: A Library for Experiment-Driven Research in Distributed Computing. *IEEE Transactions on Parallel and Distributed Systems* 33, 6 (June 2022), 1464–1477. doi:10.1109/TPDS.2021.3111159

[5] Byung-Gon Chun, Sunghwan Ihm, Petros Maniatis, Mayur Naik, and Ashwin Patti. 2011. CloneCloud: elastic execution between mobile device and cloud. In *Proceedings of the sixth conference on Computer systems*. ACM, Salzburg Austria, 301–314. doi:10.1145/1966445.1966473

[6] Peijin Cong, Junlong Zhou, Liying Li, Kun Cao, Tongquan Wei, and Keqin Li. 2021. A Survey of Hierarchical Energy Optimization for Mobile Edge Computing: A Perspective from End Devices to the Cloud. *Comput. Surveys* 53, 2 (March 2021), 1–44. doi:10.1145/3378935

[7] Eduardo Cuervo, Aruna Balasubramanian, Dae-ki Cho, Alec Wolman, Stefan Saroiu, Ranveer Chandra, and Paramvir Bahl. 2010. MAUI: making smartphones last longer with code offload. In *Proceedings of the 8th international conference on*

Mobile systems, applications, and services. ACM, San Francisco California USA,
49–62. doi:10.1145/1814433.1814441

[8] Edouard Guégain. 2024. Assessing the environmental impact of mobile applications: a measure framework toward DevGreenOps. In Proceedings of the IEEE/ACM 11th International Conference on Mobile Software Engineering and Systems. ACM, Lisbon Portugal, 88–91. doi:10.1145/3647632.3651391

[9] IEA. 2025. Energy and AI. https://www.iea.org/reports/energy-and-ai

[10] Martin Kleppmann, Adam Wiggins, Peter Van Hardenberg, and Mark McGranaghan. 2019. Local-first software: you own your data, in spite of the cloud. In Proceedings of the 2019 ACM SIGPLAN International Symposium on New Ideas, New Paradigms, and Reflections on Programming and Software. ACM, Athens Greece, 154–178. doi:10.1145/3359591.3359737

[11] Jonathan Koomey, Stephen Berard, Marla Sanchez, and Henry Wong. 2011. Im-
plications of Historical Trends in the Electrical Efficiency of Computing. *IEEE
Annals of the History of Computing* 33, 3 (2011), 46–54. doi:10.1109/MAHC.2010.28

[12] Sokol Kosta, Andrius Aucinas, Pan Hui, Richard Mortier, and Xinwen Zhang. 2012. ThinkAir: Dynamic resource allocation and parallel execution in the cloud for mobile code offloading. In 2012 Proceedings IEEE INFOCOM. 945–953. doi:10.1109/INFCOM.2012.6195845

[13] Yun Lin, Tundong Liu, Fufeng Chen, Kuan-Ching Li, and Yi Xie. 2021. An energy-efficient task migration scheme based on genetic algorithms for mobile applications in CloneCloud. *The Journal of Supercomputing* 77, 5 (May 2021), 5220–5236. doi:10.1007/s11227-020-03470-0

[14] Fangming Liu, Peng Shu, Hai Jin, Linjie Ding, Jie Yu, Di Niu, and Bo Li. 2013. Gearing resource-poor mobile devices with powerful clouds: architectures, challenges, and applications. *IEEE Wireless Communications* 20, 3 (June 2013), 14–22. doi:10.1109/MWC.2013.6549279

[15] Jens Malmodin, Nina Lövehagen, Pernilla Bergmark, and Dag Lundén. 2024. ICT sector electricity consumption and greenhouse gas emissions – 2020 outcome. *Telecommunications Policy* 48, 3 (April 2024), 102701. doi:10.1016/j.telpol.2023.102701

[16] Rui Pereira, Marco Couto, Francisco Ribeiro, Rui Rua, Jácome Cunha, João Paulo Fernandes, and João Saraiva. 2021. Ranking programming languages by energy efficiency. *Science of Computer Programming* 205 (May 2021), 102609. doi:10.1016/j.scico.2021.102609

[17] Alberto Prieto, Beatriz Prieto, Juan José Escobar, and Thomas Lampert. 2024. Evolution of computing energy efficiency: Koomey’s law revisited. *Cluster Computing* 28, 1 (Oct. 2024), 42. doi:10.1007/s10586-024-04767-y

[18] Abd. Rahman and Apol Pribadi Subriadi. 2022. Software as a Service (SaaS) Adoption Factors: Individual and Organizational Perspective. In 2022 2nd International Conference on Information Technology and Education (ICIT&E). IEEE, 31–36. doi:10.1109/icite54466.2022.9759891

[19] Weisong Shi, Jie Cao, Quan Zhang, Youhuizi Li, and Lanyu Xu. 2016. Edge Computing: Vision and Challenges. *IEEE Internet of Things Journal* 3, 5 (June 2016), 637–646. doi:10.1109/JIOT.2016.2579198

[20] Lylian Siffre, Thomas Ledoux, Renaud Pawlak, and John Guery. 2025. Local-First Software for Green IT. In *ICT4S 2025 - International Conference on Information and Communications Technology for Sustainability*. Dublin, Ireland, 1–10. https://hal.science/hal-05037019

[21] Peter Van Hardenberg and Martin Kleppmann. 2020. PushPin: towards production-quality peer-to-peer collaboration. In Proceedings of the 7th Workshop on Principles and Practice of Consistency for Distributed Data. ACM, Heraklion Greece, 1–10. doi:10.1145/3380787.3393683

[22] Rini van Solingen (Revision), Vic Basili (Original article, 1994 ed.), Gianluigi Caldiera (Original article, 1994 ed.), and H. Dieter Rombach (Original article, 1994 ed.). 2002. Goal Question Metric (GQM) Approach. (2002). arXiv:https://onlinelibrary.wiley.com/doi/pdf/10.1002/0471028959.sof142 doi:10.1002/0471028959.sof142

[23] Claes Wohlin, Per Runeson, Martin Höst, Magnus C. Ohlsson, Björn Regnell, and Anders Wesslén. 2024. *Experimentation in Software Engineering*. Springer Berlin Heidelberg. doi:10.1007/978-3-662-69306-3

[24] Yixuan Zhang, Mugeng Liu, Haoyu Wang, Yun Ma, Gang Huang, and Xuanzhe Liu. 2025. Research on WebAssembly Runtimes: A Survey. ACM Transactions on Software Engineering and Methodology (Jan. 2025). doi:10.1145/3714465