Energy Efficiency Analysis of Code Refactoring Techniques for Green and Sustainable Software in Portable Devices

Abstract

Code refactoring is a time-consuming and effort-intensive process that is applied for making improvements to source codes. There exist several refactoring techniques to improve software quality. Some of them aim to reduce the energy consumption of the software. However, the combination of applied refactoring techniques is crucial to the success rate. In addition, to provide sustainable services on portable devices such as mobile phones and laptops, which rely on batteries, improving and optimizing the energy efficiency is important. This study focuses on examining the effect of code refactoring techniques on energy consumption. A total of 25 different source codes of applications programmed in the C# and Java languages are selected for the study, and combinations obtained from refactoring techniques are applied to these source codes. The combinations applied are analyzed using the maintainability index. Power consumption estimation tools are used to measure the energy consumption of the original and refactored codes. The results show that the combinations significantly improve the software’s energy efficiency. The results will provide a better understanding of the relationship between the energy efficiency of software and refactoring techniques. Moreover, they will help developers to improve their object-oriented code in terms of both energy efficiency and sustainability.

1. Introduction

Today, energy consumption and dependence on energy are issues that concern all countries worldwide [1]. Alongside the increase in the global population, the use of information and communication technologies is also increasing. In order to maintain the continuity of these technologies, both hardware and software infrastructures are used and energy consumption increases greatly as a result of increased use [2]. Every action made to develop software has a cost and it results in an increase in the carbon emission. The approach that its practitioners call green software engineering [3] is an emerging paradigm that aims to develop green-enabled software to reduce negative impacts on the environment. The software solutions developed are based on observing innovations in the software development process followed and the refactoring technique used without disturbing the code’s function.

With the advent of electronic devices such as smartphones, tablets, and laptops, reducing energy consumption has become an important issue for researchers [4]. Further, the usage time of portable devices has increased significantly in parallel. As the use of these devices becomes more widespread, the applications developed to meet different user needs become larger and more complex. One way to reduce the energy consumption of portable devices is to improve the software quality [5]. Code refactoring is a possible method to address this problem because it supports the restructuring of existing source codes to obtain more energy-efficient code.

Considering the frequency of the need for energy in portable devices allows a better understanding of the importance of refactoring techniques in energy consumption. Object-oriented languages are common among developers, in accordance with the need for contemporary coding. Therefore, this study investigates object-oriented projects to determine the efficacy of refactoring techniques.

Specific studies giving advice for reducing energy consumption according to the code structure and software development model are available in the literature. Despite this popularity, refactoring techniques that vary and evolve dramatically are examined individually in only a few works. Arguably, it is of great significance for developers to know the change in energy consumption depending on the selected refactoring technique [6]. In the studies that address energy consumption, some studies examine energy consumption according to the selected software development model [7] (for instance, data management techniques in developing software). Furthermore, it has been found that the refactoring effectiveness is not consistent because of the difference in applications [8]. Moreover, one of the most remarkable studies that explains the effects of refactoring on energy consumption is Kim et al.’s work [9]. Some double combinations of refactoring techniques are involved in their experiment in terms of energy consumption. It is clearly seen that the study reducing energy consumption up to 2.4% was performed with codes retrieved from one programming language. The study demonstrated that the interaction of refactoring techniques should be investigated comprehensively. Moreover, yet another direction is to learn how the refactoring techniques should be combined. However, the binary combination of refactoring techniques is only investigated on embedded systems.

To the best of our knowledge, there is no comprehensive work analyzing the interaction of only triple combinations of refactoring techniques in terms of energy consumption. Further, preceding works are generally focused on a specific problem rather than presenting an overview. On the other hand, evaluating refactoring techniques individually does not give beneficial advice about energy consumption to practitioners. On the contrary, using refactoring techniques without considering the effects of their combinations on the source code could be misleading in interpreting energy consumption. The current study describes the most detailed experiment with regard to the number of refactoring techniques in the combinations. In this study, the effects of the use of five different refactoring techniques and their triple combinations on energy consumption are investigated with two software applications including 25 source files. The experiment performed in this paper comprises code-level modifications. In the study, we use software metrics and compared measurements from software estimation tools to find the optimal combination of software quality and energy. The findings will help developers to improve their object-oriented code for both energy efficiency and sustainability. The remainder of the study is organized as follows: the second section contains a summary of related studies. The third section covers the materials and methods of the experimental work. In the fourth section, the results of the study are given. The fifth section details the threats to the validity of the study. The final section discusses the conclusions and future directions. Figure 1 shows a summary of this paper.

2. Related Studies

Green software should consist of effective, low-resource-consuming, and, in particular, profitable codes in terms of energy consumption, because one way to reduce the energy consumption of electronic devices such as smartphones, tablets, and laptops is to improve the software quality [5]. Refactoring the code is one possible way to address this issue. Green software studies with code refactoring techniques, which can be considered trailblazers, have become more prevalent in the literature in the last decade [10,11].

Pioneering studies on the relationship between code refactoring techniques and software energy efficiency were conducted by Silva et al. [12] and Gottschalk et al. [13]. Silva et al. [12] investigated the change in energy consumption values after the “Inline Method”, which is one of the most widely used refactoring techniques, was applied to two different embedded systems. It was observed that refactoring techniques had a positive effect on energy consumption, especially in mobile devices with an Android operating system. Gottschalk et al. [13] optimized the energy-wasteful code detected in the source codes of mobile device applications by refactoring techniques. They also saw energy consumption as a major issue for Android devices and suggested an approach to reduce the energy consumption of applications by reengineering processes, including code refactoring.

One of the most comprehensive studies investigating the effects of refactoring techniques in energy consumption was performed by Sahin et al. [8]. They used six code refactorings provided by the Eclipse IDE to 9 Java programs and analyzed their energy consumption. According to their findings, refactoring techniques lead to either an increase or decrease in energy consumption. Since every application has special characteristics, this case seems to be not consistent. Park et al. [6] measured the energy consumption values of C++ codes based on 63 different refactoring techniques. In this measurement, 33 techniques were identified as energy-efficient techniques. In the study, the energy consumption values in the combination of techniques were not considered in relation to the interaction.

Experiments in subsequent studies have shown that refactoring techniques have a positive effect on energy consumption in mobile devices, especially those using the Android operating system [14]. Morales et al. [15] proposed a model validation approach called EARMO. This approach proposes refactoring techniques that can reduce energy consumption.

Kim et al. [9] carried out a study examining the energy consumption values by applying more than one refactoring technique together. This study is one of the most remarkable studies explaining the effects of refactoring techniques on energy consumption. Binary combinations with seven different refactoring techniques were tested on embedded system codes. However, binary combinations were produced based on similarity. Sehgal et al. [16] investigated how refactoring plays an important role in reducing power usage. This study revealed that applying appropriate refactoring techniques reduces battery consumption. As a result, it was emphasized that improving the code with the refactoring technique is a good step towards energy efficiency.

Recently, in addition to existing studies, researchers have focused on choosing the order of refactoring techniques that helps to achieve optimum software sustainability [17,18], eliminating applications with a bad smell in mobile applications using refactoring techniques; there have also been studies on the effect of code on energy optimization [19].

The studies listed above have some limitations, which are as follows: (1) existing studies have addressed energy consumption as an energy-saving problem; (2) they have not dealt with energy consumption in detail in terms of the interaction of refactoring techniques; (3) using refactoring techniques without considering the effects of their combinations on the source code could be misleading when interpreting energy consumption rates. The main motivation of this study is to fill this gap by applying triple combinations of refactoring techniques on source codes for mobile phones and laptops.

3. Materials and Methods

This section provides energy consumption estimations, including a detailed demonstration of the conceptual framework of the experimental work, applied refactoring techniques, data collection, analysis of combinations, and hardware configuration.

Figure 2 shows the conceptual framework of the present study. The general aim of the study is to investigate combinations of code refactoring techniques in terms of energy efficiency in open-source object-oriented software applications.

First, source codes written in Java and C# and the refactoring techniques to be applied were selected. Second, a triple combination list was prepared from the selected refactoring techniques. According to our knowledge, there is not any comprehensive study to date that analyzes the interaction of triple combinations of refactoring techniques in terms of energy consumption. In addition to this, energy usage can be reduced if the techniques are used for multiple different parts of a source code [9]. Third, after constructing all the combinations of refactoring techniques, they were integrated into the source codes to be applied. Next, the triple combination list was analyzed using the software metric maintainability index [20]. Thus, it was detected which combinations were to be employed by regarding the change in metric value. Then, detected combinations were integrated into the source codes to be applied. After this, energy consumption estimates were made for the source codes, which were then be called the “refactored codes” and the “original codes”. Finally, a general evaluation of the original and refactored codes was conducted.

3.1. Refactoring Techniques

Code refactoring is a disciplined technique for improving software quality by altering the internal structure of code without changing its external behavior. Although some basic operations including refactoring techniques are offered in the development tools, the main purpose of which is to improve the readability, performance, and maintenance of the code, special methods can also be developed. Software developers, engineers, or researchers want to use more stable refactoring techniques to maintain open-source software development [6].

Refactoring techniques can be performed manually or automatically by developers. They can also be applied depending on the coding type and can be applied to many computer programs in the software industry. Many refactoring techniques can be used to obtain more energy-efficient code. In addition, refactoring techniques consider energy efficiency as a factor in software quality [6]. However, while some of them make a positive contribution to energy consumption, others negatively affect energy consumption [9]. Positive refers to reducing energy consumption, while negative refers to increasing energy consumption.

To examine the source codes in terms of energy efficiency, five refactoring techniques [4,6,9,21], known to contribute positively to energy efficiency, were selected for the study since they have a high frequency of practical use, as shown in a literature review [22], and are easy to implement in C# and Java. In addition, the selected techniques significantly reduce the number of lines of code or complexity of the applications, so the contribution of these techniques to energy efficiency in applications is intriguing. Details of these are given in

Table 1. Refactoring techniques.

Notation	Name	Description
$R_1$	Encapsulate field	Makes a public field private;
		Creates getter and setter methods [6].
$R_2$	Inline temp	Replaces variable references with itself [4].
$R_3$	Introduce explaining variable	Adds variables in the code where there is a complex expression to make the expression simpler  [6].
$R_4$	Simplify nested loop	Converts the nested loop structure into a single loop [9].
$R_5$	Replace delegation with inheritance	Replaces the delegate with inheritance [21].

. At the same time,

Table 2. Motivating examples.

Notation	Code Example of Refactoring Technique
$R_1$
$R_2$
$R_3$
$R_4$
$R_5$

illustrates motivating examples of the refactoring techniques used in the study.

3.1.1. Encapsulate Field

Encapsulation is one of the refactoring techniques that alleviates the software maintenance process. The main purpose of this refactoring technique is to set access permissions of a variable. If there is any performance concern, encapsulation may generate an adverse effect. This means that using getters and setters may invoke additional function calls. Thus, it may lead an application to perform less well [23]. However, this technique is generally a good design practice that allows the encapsulation of the fields of a class and might have an impact on energy efficiency [6]. Get and set functions are configured by selecting a specific field.

3.1.2. Inline Temp

The problem emerging with assigning a result to a temporary variable before expressing it is generally addressed with the extract method. Instead, inline temp obtains results by invoking the value returned by the function. This is one of the processes that increases the readability of a program. Note that, while applying inline temp, it should be controlled whether the value returned by the function is to be used for an extensive operation. If an extensive operation is needed, the inline temp can be considered more viable. In addition, eliminating temporary variables speeds up the fetching of redundant temporary variables from both the main and cache memories [4]. This approach improves performance and maintains the same level of energy efficiency, which is considered a positive improvement [4,6].

3.1.3. Introduce Explaining Variable

Low-level simplification of complex expressions and conditional expressions is among the characteristics of refactoring types. One of them, the introduce explaining variable, is a low-level code-based refactoring technique that simplifies a complex expression [24]. If it detects a complex expression within the technical code, it puts the result of the expression or parts of the expression in a temporary variable with a name describing the purpose [25]. Thus, the complex expression is simplified by introducing new variables into the code.

3.1.4. Simplify Nested Loop

If a loop has a double or more dimensional structure, this loop should be simplified. This simplification is possible by reducing the dimensions of the loop. For instance, if three-dimensional structures are reduced to two-dimensional, this is a suitable refactoring operation. Dimension reduction of multi-dimensional loops helps to reduce energy consumption. Moreover, numerous loops can be simplified, making the code even more readable and energy-efficient [9].

3.1.5. Replace Delegation with Inheritance

Inheritance is used to share functionality between two classes [21]. Delegation allows the dynamic changing of the delegate, which cannot be done with a superclass in most object-oriented programming languages. If one replaces delegation with inheritance, it makes the class a delegate inheriter by purging the delegate method. It also eliminates the need to create a delegation method for each new delegate class method. Thus, the number of lines of code can be reduced.

3.2. Data Collection

Since games on portable devices are energy-intensive applications [26], game-based built-in applications that have existed for some years and have an active user community were determined as the primary criteria in the dataset selection of our study. Another criterion is that the applications must be compatible with at least three refactoring techniques since it is possible to reduce the energy consumption if the techniques are applied to several different sections within a source code [9]. Finally, an attempt is made to analyze plain codes, which would allow the desired changes and contain object relations. The study focuses on Java and C# applications for object-oriented programming and covers the findings of these languages. They are frequently used as they are the most compatible with the tools analyzed for the maintainability of the software [27] and are preferred in energy efficiency studies [28,29]. These two languages have similar syntax, and applications with common goals written in these two languages show similar characteristics in terms of class encapsulation, polymorphism, and reusability [30]. However, it is not known exactly whether they show similarity in terms of energy efficiency.

Game 2048 is a single-player numbers game and is played on a 4 × 4 grid. The aim of the game is to reach the number 2048 by combining the numbers in the 16 squares on the screen with each other. The 2048 applications are game-based. The 2048 desktop application is a Windows Form-based application coded in C#. The 2048 mobile application is an Android application coded in Java. These applications are small open-source apps available on Github, with an average of around 1000 lines of code. They include class encapsulation, inheritance, mathematical operations, global variables, local variables, and loop structures. In addition, basic control structures of sequence and iteration are detected in terms of source code.

Open-source code is preferred in applications in order to be able to access the source code and to test applications written in Java on an Android device. The source codes of the applications used in the study were arranged to apply the selected refactoring techniques, and the edited versions are expressed as the original source code in the rest of the article. In addition, the application of refactoring techniques individually and in combination was performed manually in this study. Before applying the agreed refactoring techniques, the size and complexity of the experimental applications were measured. To extract the static code metrics of these applications, LocMetrics [31] was used. This tool is used to count Lines of Code (LOC), Physical Line of Code (SLOC-P), Logical Line of Code (SLOC-L), and McCabe’s Cyclomatic Complexity (CC).

1.

LOC is found by counting all source code, including blank lines, comment lines, and dead codes [32]. Code lines can be defined as SLOC-P and SLOC-L.

2.

SLOC-P is calculated by subtracting the total number of blank lines and comment lines from the number of source code lines [33].

3.

SLOC-L is calculated by counting the program statements that are likely to be executed [34].

4.

CC tries to measure the complexity of the related program using the control flow graph [35].

These metrics are the oldest and most widely used size measurements [36,37]. LOC and CC can affect energy consumption and software quality [38]. As the dimension of CC increases, it becomes extremely difficult to test a software program [39]. The obtained values of the original source codes of the experimental applications are given in

Table 3. Summary of experimental applications.

Name	File Number	LOC	SLOC-P	SLOC-L	CC
2048 (desktop application) ${}^1$	8	806	578	353	92
2048 (mobile application) ${}^2$	17	1204	938	698	132

¹https://github.com/retecata/2048-in-Csharp (accessed on 12 September 2021); ² https://github.com/roxrook/2048-android (accessed on 9 December 2021); LOC: lines of code; SLOC-P: physical executable source lines of code; SLOC-L: logical executable source lines of code; CC: McCabe’s cyclomatic complexity.

. This table indicates that the mobile application of 2048 has more files than the desktop application of 2048. Moreover, the LOC, SLOC-P, and SLOC-L of the 2048 desktop application code are smaller than the 2048 mobile application code. According to the value of CC in the table, the mobile application’s code complexity is greater.

3.3. Analysis of Combination List

Ten different combination lists were obtained from the triple combinations of refactoring techniques. The combination list is represented by $C_L=(C_1,C_2,\cdots ,C_i)$, and i consists of integer variables, where i is the number of combinations. The resulting list is shown in

Table 4. Representation of all possible combinations of applied techniques.

Notation	${\mathit{C}}_1$	${\mathit{C}}_2$	${\mathit{C}}_3$	${\mathit{C}}_4$	${\mathit{C}}_5$	${\mathit{C}}_6$	${\mathit{C}}_7$	${\mathit{C}}_8$	${\mathit{C}}_9$	${\mathit{C}}_{10}$
$R_1$	X	X	X	-	-	-	X	X	X	-
$R_2$	X	-	-	X	X	-	X	X	-	X
$R_3$	X	X	-	X	X	X	-	-	X	-
$R_4$	-	X	X	X	-	X	X	-	-	X
$R_5$	-	-	X	-	X	X	-	X	X	X

C₁: Combination of R₁, R₂, R₃; C₂: Combination of R₁, R₃, R₄; C₃: Combination of R₁, R₄, R₅; C₄: Combination of R₂, R₃, R₄; C₅: Combination of R₂, R₃, R₅; C₆: Combination of R₃, R₄, R₅; C₇: Combination of R₁, R₂, R₄; C₈: Combination of R₁, R₂, R₅; C₉: Combination of R₁, R₃, R₅; C₁₀: Combination of R₂, R₄, R₅.

. While “X” denotes the selection of the refactoring technique for combination, the refactoring techniques having the “-” label were eliminated.

The list was analyzed with the maintainability index metric value. The aim was to check whether the combinations of maintainability measurement values contributed positively to the energy consumption values. The maintainability index ($MI$) is a software measure that measures how maintainable (supporting and modifying) the source code is. The $MI$ formula consists of a combination of $CC$ and Halstead Volume ($HV$) [40]. This metric has an important place among software metrics as it provides information about the complexity, maintenance, and maintainability of the code. $MI$ is calculated by Equation (1) [20]:

$$MI=171-5.2\times ln\left(HV\right)-0.23\times \left(CC\right)-16.2\times ln\left(LOC\right)$$

(1)

According to Coleman, an $MI$ value above 85 indicates that the software is highly maintainable, a value between 85 and 65 indicates moderate maintainability, and a value below 65 indicates that the system is difficult to maintain and has low maintainability [20]. The $MI$ was calculated using the Code Metrics [33] and JHawk [41] tools for the 2048 desktop applications coded in C# and the 2048 mobile applications coded in Java, respectively.

3.4. Energy Consumption Estimation

Energy consumption was estimated for the source codes written in C# and Java programming languages. Other object-oriented programming languages were not within the scope of this study. Two open-source applications were measured.

To estimate the energy consumption, two software power estimators named Intel Power Gadget [42] and Trepn Profiler [43] were used. They both support object-oriented code-based estimation. The Intel Power Gadget tool includes elapsed time, packet power limit, processor frequency, graphics processing unit frequency, processor temperature, average, and total power of the processor. The Trepn Profiler samples data every 100 milliseconds and presents them in different data visualization modes. It allows real-time raw data transfer for offline analysis [44]. The tools used save the results as a CSV file. The energy unit is converted by the Intel Power Gadget by calculating with Equation (2) [45] for the Trepn Profiler:

$$Energy\left(Joule\right)=\left(\frac{power}{{10}^6}\right)W\times \left(\frac{profilingtime}{{10}^3}\right)s$$

(2)

Watts (W) are used to measure power, while joules (J) are used to measure the cumulative watt-seconds (W-s) required to perform the work [46,47]. The experiments run 10 tests per original and refactored code because the results after over 10 runs aimed to reduce the impact of cold starts and cache effects [48] so that possible noise or outliers in the results could be reduced. Test measurements were carried out in periods of 300 s. When the tests are all the same length, the average watt (average power) is commonly used [46,47]. During the measurements, the energy consumption values consumed by the programs in consecutive time intervals tend to differ. Therefore, it was very important for this study to determine the average power consumption per second in each programming language. Thus, the average was considered significant in the current study and the energy consumed in joules during a test was calculated by multiplying the average watts by the seconds. Energy consumption values were recorded for both laptop and mobile phone devices. The Intel Power Gadget was used to save the laptop’s values. The Trepn Profiler was chosen to record the energy footprint of the Android-based Java application. The desktop app experiments were performed offline on a laptop with Windows 10 Pro [49] as an operating system. The laptop device had the following configurations: Intel Core i7-8750H, 2.20 GHz, 8 GB RAM, and 256 GB disk space. The Android-based Java project was tested on a Samsung Galaxy J7 Prime running Android 8.1. The device was equipped with an octa-core, 1.6 GHz Cortex-A53 Qualcomm Snapdragon 617 processor, 3 GB system memory, and 16 GB storage. Power profiles containing cumulative energy consumption values were saved as .csv files, which were then analyzed offline according to the recommended method. For the laptop, measurements were taken in both idle and airplane mode. The devices that provided external communication, such as Wi-Fi and Bluetooth, were set to be offline. Network power was not taken into account as all the experiments were performed offline. In addition, the laptop and mobile phone experiments were performed at the same time interval (5 min) [23,50]. Energy consumption depends on execution time and power, as shown in Equation (2). In this study, the execution time was kept constant and the common time was determined for both platforms. The minimum recommended time for Android tools was used for the laptop measurements. Thus, the same time interval was used to obtain comparisons based on reliable results. Moreover, the minimum number of applications required for the experiment (OS core services, energy metering tool, metered application, etc.) was allowed in concurrent execution and each experiment was performed with 100% battery. The same configuration was also applied to the mobile phone to produce a reliable evaluation.

4. Results

The Wilcoxon signed-rank statistical test [51], which is a type of non-parametric test, was used to determine whether the difference between the amount of energy consumed by the original code and refactored code of each applications was statistically significant. The Wilcoxon signed-rank test was run at a significance level of 0.05 to judge energy consumption before refactoring and after refactoring. This test was chosen since it has no bias about the data distribution for both applications. In hypothesis zero ($H_0$), the distribution in the energy consumption results of the refactored code was the same as the distribution in the energy consumption results of the original code. Conversely, if there was a significant difference between the distribution of energy consumption results of the refactored code and the distribution of energy consumption results of the original code, the hypothesis was one ($H_1$). If the p value was less than 0.05, the distribution of energy consumption results of the refactored codes differed significantly from the distribution of energy consumption results of the original code. The results of the test given in

Table 5. Results of Wilcoxon signed-rank test for the original and refactored codes ($H_0$: p > 0.05, $H_1$: p < 0.05).

	${\mathit{R}}_1$	${\mathit{R}}_2$	${\mathit{R}}_3$	${\mathit{R}}_4$	${\mathit{R}}_5$	${\mathit{C}}_1$	${\mathit{C}}_3$	${\mathit{C}}_4$
2048 ${}^a$ (p value)	$0.007$	$0.005$	$0.011$	$0.005$	$0.022$	$0.005$	$0.009$	$0.005$
2048 ${}^b$ (p value)	$0.031$	$0.028$	$0.028$	$0.018$	$0.043$	$0.022$	$0.018$	$0.025$

^a Original code of desktop application, ^b Original code of mobile application.

show that the distribution was different for the original and refactored code. It can be seen that the p values of the original and refactored code were less than 0.05. Therefore, we rejected $H_0$, which was the opposite of the significant difference among the test objectives.

In the 2048 desktop application, there was a statistically significant difference (p ≤ 0.022) between the original and refactored codes. The differences between the original and refactored codes in the 2048 mobile application were also statistically significant (p ≤ 0.043). As a result, it is clearly seen from Table 5 that $R_1$, $R_2$, $R_3$, $R_4$, $R_5$, $C_1$, $C_3$, and $C_4$ achieved significantly different results to the original code of the applications.

As a result of the list analysis, combinations of refactoring techniques with optimum maintainability index values were selected.

Table 6. The effect of the maintainability index on the combinations in the source code of the applications and the percentage change rates of the combinations.

Name	$\mathit{MI}$	Org.	${\mathit{C}}_1$	${\mathit{C}}_2$	${\mathit{C}}_3$	${\mathit{C}}_4$	${\mathit{C}}_5$	${\mathit{C}}_6$	${\mathit{C}}_7$	${\mathit{C}}_8$	${\mathit{C}}_9$	${\mathit{C}}_{10}$
2048 (desktop	Value	66	70	68	71	70	69	67	67	68	68	67
application)	%change	-	+6.06	+3.03	+7.58	+6.06	+4.54	+1.52	+1.52	+3.03	+3.03	+1.52
2048 (mobile	Value	115.63	121.00	117.96	122.10	121.90	116.00	119.62	119.96	116.57	115.95	118.74
application)	%change	-	+4.64	+2.02	+5.60	+5.42	+0.32	+3.45	+3.74	+0.81	+0.27	+2.69

Org.: Original, MI: Maintainability index.

shows the maintainability values extracted from the Code Metrics and JHawk tools for each of the selected combinations. While the $MI$ value of the original source codes of the 2048 mobile application coded with Java was 66, the $MI$ value of the original source codes of the 2048 desktop application coded with C# was 115.63.

Regarding the results from the maintainability measurements of the two applications, it is apparent from the values of the maintainability index that the $MI$ of $C_3$, which is a combination of $R_1$, $R_4$, and $R_5$, has the highest value among all other combinations for both applications. This means that $C_3$ increased the maintenance effort of these applications. The lowest maintainability index for the 2048 mobile application is $C_9$, which is a combination $R_1$, $R_3$, and $R_5$. However, it achieved slightly higher results than the maintainability index of the original codes of this application. This shows that $C_9$ contributes slightly to the maintenance effort of this application. Another important point is that the distinctive technique is $R_3$ for $C_9$, because this technique makes a difference in terms of maintainability on the interaction between techniques. According to Table 6, the values obtained from the tools show a significant increase in $MI$ values for $C_1$, $C_3$, and $C_4$ compared to the original codes in both applications. These were determined as the optimum combinations. The details of the optimum combinations of the applications are given in

Table 7. Demonstration of optimum combinations of 2048 desktop and mobile applications.

Notation	${\mathit{C}}_1$	${\mathit{C}}_3$	${\mathit{C}}_4$
$R_1$	X	X	-
$R_2$	X	-	X
$R_3$	X	-	X
$R_4$	-	X	X
$R_5$	-	X	-

.

Table 8. Results of energy consumption. All experiments were carried out at same time interval (300 s).

Energy Consumption (J) of 10 Runs (Median, Mean, S.D.)
Name	Type	Org.	${\mathit{R}}_{\mathbf{1}}$	${\mathit{R}}_{\mathbf{2}}$	${\mathit{R}}_{\mathbf{3}}$	${\mathit{R}}_{\mathbf{4}}$	${\mathit{R}}_{\mathbf{5}}$	${\mathit{C}}_{\mathbf{1}}$	${\mathit{C}}_{\mathbf{3}}$	${\mathit{C}}_{\mathbf{4}}$
2048 (desktop application)	Median	1465.65	1442.00	1435.50	1436.50	1414.75	1446.44	1406.00	1398.58	1391.45
	%change	-	−1.61	−2.06	−1.99	−3.47	−1.31	−4.07	−4.58	−5.06
	Mean	1462.45	1440.46	1436.90	1432.36	1415.18	1446.65	1407.49	1399.83	1391.79
	%change	-	−1.50	−1.75	−2.06	−3.23	−1.08	−3.75	−4.28	−4.83
	S.D.	15.58	16.50	13.38	12.26	13.18	16.00	13.36	19.71	6.41
2048 (mobile application)	Median	184.59	179.36	178.24	176.90	172.59	182.38	171.74	167.64	171.90
	%change	-	−2.83	−3.44	−4.17	−6.50	−1.19	−6.96	−9.18	−6.88
	Mean	184.71	179.62	177.94	177.02	171.22	181.55	171.42	168.46	170.62
	%change	-	−3.03	−3.67	−4.70	−7.30	−1.71	−7.20	−9.33	−7.63
	S.D.	4.46	5.57	3.1	5.74	5.32	4.43	5.39	5.48	5.66

S.D.: Standard deviation.

, which includes the experimental results of the energy consumption analysis, reports the mean, median, and percentage change of energy consumption measurements. It also reports the standard deviation of the measurements.

The average energy consumption for the original code of the game in the 2048 desktop application was 1462.45 J, while the average energy consumption for the original code of the mobile application was measured as 184.71 J.

4.1. Assessing Energy Consumption of Each Refactoring Technique

Each refactoring technique has a special code-modifying behavior. To determine this, they should be examined individually. To reduce the impact of uncontrolled behavior and to control the possibility of reducing energy consumption, we first analyzed the original code and the impact of each refactoring technique on the source codes individually. The energy consumption of the applications was measured ten times before each refactoring technique was applied and ten times after each refactoring technique was applied. The results are shown in Figure 3 and Figure 4.

As can be observed in Table 8, the energy reduction rate in using $R_4$ seems quite impressive for both applications. When implementing $R_5$, the probability of a positive contribution to energy efficiency is lower, whereas, when performing $R_4$, the probability of a contribution to energy efficiency is higher for the combinations, because the $R_5$ saves the smallest amount of energy in both applications. Results from the application of each of the five refactoring techniques showed that all of the techniques could save energy. Among these, the $R_4$ technique was the one that provided the best energy savings, as seen in Figure 3 and Figure 4. The $R_5$ technique provided the smallest energy savings in the 2048 application. This is because, when applied to the original code of 2048, the reduction in method calls did not cause a significant reduction in byte code calls and consequently had little impact on energy efficiency. The energy consumption of $R_2$ for the 2048 mobile application is more consistent than the original codes as the interquartile range is smaller than the original code values.

Although $R_1$, $R_2$, and $R_3$ techniques differed between applications, they contributed positively to energy efficiency for both applications.

4.2. Assessing Energy Consumption of Combinations

Figure 5 and Figure 6 show the details of the cumulative energy consumption for codes refactored by the original codes and combinations of the refactoring techniques. In order to evaluate the selected combinations in terms of energy consumption, Table 8, Figure 5 and Figure 6 were examined.

The combination of the $R_1$, $R_2$, and $R_3$ techniques showed that $C_1$ reduced the energy consumption for both applications. $C_1$ affects the most costly blocks, cos(), sus(), stanga(), and drepta(), in the 2048 desktop application source code. In the 2048 mobile application, $C_1$ affects the mergeLeft(), mergeRight(), mergeUp(), and mergeDown() methods in the Matrix class. Each block has a separate energy cost. However, replacing complex expressions in code blocks with a variable reduced the energy significantly. $C_1$ also allows variables to be allocated less space in memory and shortens the time to retrieve them from the cache. As a result, the number of cycles during instruction execution is reduced, and this combination reduces the energy consumption. Similarly, $C_3$, which is a combination of $R_1$, $R_4$, and $R_5$, tended to reduce the energy consumption of the applications. $C_3$ affects, in the other most costly blocks, processCmdKey(), which have loops, comparisons, method invocations, parameter passing, and boolean operations, in the 2048 desktop application. Game class, which is the source code of the desktop application, is affected by the $R_5$ implementation. This class invokes the processCmdKey(). In the 2048 mobile application, onCreate() and onMove() are the code blocks that $C_3$ affects more. After refactoring, loop structures and method invocations provided significant energy savings for both applications. However, $C_3$ achieved a lower energy consumption rate for the 2048 mobile application than the 2048 desktop application. In this application, the interaction of refactoring techniques draws attention as a result of the refactoring combination obtained by the $R_1$, $R_4$, and $R_5$, because the deletion of temporary variables affected the number of iterations in the single loop structure and provided a large amount of energy reduction. In the combination $R_1$, $R_4$, and $R_5$, $R_4$ is a distinctive technique in terms of energy consumption between applications. Moreover, the energy consumption ranges of $C_3$ varied by several orders of magnitude, and the lower quartile of $C_3$ for the 2048 mobile application was lower than the others.

$C_4$, which is a combination of $R_2$, $R_3$, and $R_4$, contributed positively to energy efficiency for both applications. $C_4$ affects the blocks gameover(), newGameToolStripMenuItemClick(), and processCmdKey() in the desktop application source code. In the Java source code, $C_4$ affects mergeLeft(), mergeRight(), mergeUp(), mergeDown(), and matrix() code blocks. This combination refactors array comparisons, assignments, and loop structure in both source codes, which contributes the most to the cost. However, the percentage of change in energy consumption for the 2048 mobile application of $C_4$ was close to the percentage of change in energy consumption of the $R_4$ technique applied to the code, which is associated with the simplification of the loop structure. Moreover, the percent change in the energy consumption of $C_4$ did not approximate the mathematical addition of the techniques’ percent change in individual energy consumption [9]. Because the techniques, including $C_4$, do not interact with each other, it was observed that the change in the number of codes for the 2048 mobile application was small and energy efficiency was less affected.

The results validate that the maintainability index, which indicates the maintainability of the code, is useful in choosing combinations of refactoring techniques for the energy consumption of the 2048 application coded in C#. However, this does not apply to all the selected combinations of the 2048 application coded in Java. In summary, from the graphs in Figure 5 and Figure 6, and Table 8, we can conclude that the refactoring technical combinations generally positively affected energy consumption.

5. Threats to Validity

First, the scope of the experiment was limited to two types of programming languages. Second, manual refactoring is often error-prone and takes time. In this study, this process was driven manually. Energy consumption thus varied depending on how the programmers refactored the original code. Third, we tried to conduct our experiments on commonly used portable devices, such as laptops and mobile devices, and in controlled environments. Thus, we cannot guarantee that the results would be the same for different circumstances, such as industrial devices and environments. Lastly, the proposed combinatorial method involves triple combinations. However, higher levels of combinations have not been considered yet. Although this reduces the validity of the experiment, such an extension, pushing the limits of the scale of the experiment, can be regarded as being beyond the scope of the paper. However, we believe that our work provides new insights into how to improve the structure of coding to contribute to green software.

6. Conclusions and Future Remarks

In this study, the impact of code refactoring technique combinations on energy consumption has been investigated. The proposed approach has effectively been implemented on 2048 mobile and 2048 desktop application datasets, showing superiority in predicting the combination of refactoring techniques over previous studies in terms of how the refactoring techniques should be combined. Moreover, the contribution of the maintainability measurement values to the energy consumption values of the combinations has also been looked into. The proposed method yielded an optimal combination of refactoring techniques to keep energy consumption to a minimum. The maintainability index is useful in choosing combinations of refactoring techniques for the energy consumption of the 2048 desktop application. However, this cannot be said for all selected combinations of the 2048 mobile application. This is related to the software features of the Java source code used and the interaction of the techniques. For instance, although the Java source code uses loops of specified length and dynamic method invocation as in the C# source code, the overhead of variable declaration resists the energy saved for the 2048 mobile application. Therefore, it is necessary to develop complex software metrics including MI to estimate the energy consumption of all combinations. Additionally, the paper provides the following contributions:

1.

If the selected refactoring techniques ($R_1$, $R_2$, $R_3$, $R_4$, $R_5$) reduce the energy consumption in an application, they will have a positive impact on the three combined refactoring techniques ($C_1$, $C_3$, $C_4$).

2.

When incompatible refactoring techniques are used together for the source code, energy consumption cannot be reduced as desired.

In future works, we plan to release an upgraded version of the framework for other types of programming languages. Moreover, the proposed method will be adapted to produce a combination of refactoring techniques that do not only consider energy consumption but also model the execution time allocated to complete refactoring. Finally, heuristics and combinatorial methods will be investigated to construct refactoring combinations. If historical data are recorded, the models forecasting energy consumption help in combining refactoring techniques.