84
MINING ENERGY-AWARE COMMITS: EXPLORING CHANGES PERFORMED BY OPEN-SOURCE DEVELOPERS TO IMPACT THE ENERGY CONSUMPTION OF SOFTWARE SYSTEMS Por Irineu Martins de Lima Moura M.Sc. Dissertation Universidade Federal de Pernambuco [email protected] www.cin.ufpe.br/~posgraduacao RECIFE 2015

Por Irineu Martins de Lima Moura - UFPE...Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring

  • Upload
    others

  • View
    4

  • Download
    0

Embed Size (px)

Citation preview

Page 1: Por Irineu Martins de Lima Moura - UFPE...Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring

MINING ENERGY-AWARE COMMITS: EXPLORINGCHANGES PERFORMED BY OPEN-SOURCE DEVELOPERSTO IMPACT THE ENERGY CONSUMPTION OF SOFTWARE

SYSTEMS

Por Irineu Martins de Lima Moura

M.Sc. Dissertation

Universidade Federal de [email protected]

www.cin.ufpe.br/~posgraduacao

RECIFE2015

Page 2: Por Irineu Martins de Lima Moura - UFPE...Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring

Universidade Federal de Pernambuco

Centro de InformáticaPós-graduação em Ciência da Computação

MINING ENERGY-AWARE COMMITS: EXPLORING CHANGESPERFORMED BY OPEN-SOURCE DEVELOPERS TO IMPACT THE

ENERGY CONSUMPTION OF SOFTWARE SYSTEMS

Por Irineu Martins de Lima Moura

A M.Sc. Dissertation presented to the Centro de Informática

of Universidade Federal de Pernambuco in partial fulfillment

of the requirements for the degree of Master of Science in

Ciência da Computação.

Advisor: Fernando José Castor de Lima Filho

RECIFE2015

Page 3: Por Irineu Martins de Lima Moura - UFPE...Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring

Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571

M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring changes performed

by open – source developers to impact the energy consumption of software systems / Irineu Martins de Lima Moura – Recife: O Autor, 2015.

83 f.: il., fig., tab. Orientador: Fernando José Castor de Lima Filho. Dissertação (Mestrado) – Universidade Federal de

Pernambuco. CIn, Ciência da Computação, 2015. Inclui referências e apêndice.

1. Engenharia de software. 2. Mineração de dados. 3. Consumo de energia. I. Lima Filho, Fernando José Castor de (orientador). II. Título. 005.1 CDD (23. ed.) UFPE- MEI 2016-012

Page 4: Por Irineu Martins de Lima Moura - UFPE...Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring

Dissertação de Mestrado apresentada por Irineu Martins de Lima Moura à Pós

Graduação em Ciência da Computação do Centro de Informática da Universidade Federal

de Pernambuco, sob o título “Mining Energy-Aware Commits: Exploring changes

performed by open-source developers to impact the energy consumption of software

systems” orientada pelo Prof. Fernando José Castor de Lima Filho e aprovada pela

Banca Examinadora formada pelos professores:

________________________________________________

Prof. André Luís de Medeiros Santos

Centro de Informática / UFPE

_________________________________________________

Prof. Fernando Marques Figueira Filho

Departamento de Informática e Matemática Aplicada/ UFRN

_________________________________________________

Prof. Fernando José Castor de Lima Filho

Centro de Informática / UFPE

Visto e permitida a impressão.

Recife, 24 de agosto de 2015.

___________________________________________________

Profa. Edna Natividade da Silva Barros Vice-Coordenador da Pós-Graduação em Ciência da Computação do

Centro de Informática da Universidade Federal de Pernambuco.

Page 5: Por Irineu Martins de Lima Moura - UFPE...Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring

Dedico essa dissertação a todos aqueles que sempre me

motivaram durante essa pequena jornada.

Page 6: Por Irineu Martins de Lima Moura - UFPE...Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring

Acknowledgements

Dois anos e meio depois e o que para mim parecia ser um vislumbre distante está defato se materializando. Reconheço, entretanto, que sem o suporte de várias pessoas talvez nãoestivesse escrevendo esses agradecimentos. À minha família e especialmente à minha mãe,agradeço o apoio constante mesmo nos momentos em que eu estive ausente (e foram muitos!).À minha namorada Evelyn, agradeço a infinita paciência, a incondicional confiança no meupotencial e todos os momentos bons que passamos juntos nesses últimos anos. Sou gratotambém aos meus amigos pelas risadas e pela motivação constante, em especial agradeço aoGustavo e ao Felipe, sem os quais todo o trabalho construído para minha dissertação não seriapossível. Gostaria de agradecer imensamente ao meu orientador Fernando Castor, que errouem me escolher como seu aluno de iniciação científica durante a graduação, persistiu tambémaceitando me orientar no trabalho de conclusão de curso e não satisfeito resolveu que seriauma boa ideia me orientar no mestrado, é muita ingenuidade para um professor só! Agradeçotambém aos meus colegas de trabalho, tanto aqui quanto nos EUA, pela paciência e compreensãoprincipalmente nas últimas etapas. Por fim, agradeço ao CIn e a UFPE por me proporcionaremtodo o aprendizado dos últimos anos.

Page 7: Por Irineu Martins de Lima Moura - UFPE...Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring

Resumo

O controle do consumo de energia tem ganhado cada vez mais atenção como outrotipo de interesse ao qual desenvolvedores de software devem estar atentos. Antes esse tipo depreocupação era principalmente o foco de designers de hardware e desenvolvedores de baixo-nível, como por exemplo, desenvolvedores de drivers de dispositivos. Entretanto, devido àubiquidade de dispositivos dependentes de bateria, qualquer desenvolvedor deve estar preparadopara enfrentar essa questão. Logo, entender como eles estão lidando com o consumo de energiaé crucial para estarmos aptos a auxiliá-los e para prover uma direção adequada para pesquisasfuturas.

Com o intuito de ajudar nesse sentido, essa tese explora um conjunto de mudanças desoftware, isto é, commits, para entender melhor sobre os tipos de soluções que são implementadasde fato por desenvolvedores de código aberto quando os mesmos devem lidar com o consumode energia. Nós utilizamos o GITHUB como nossa principal fonte de dados, uma plataforma dehospedagem de código fonte para o desenvolvimento colaborativo de projetos de software, eextraímos uma amostra dos commits disponíveis entre vários projetos diferentes. Dessa amostra,nós manualmente selecionamos um conjunto de commits "energy-aware", isto é, qualquer commitque se refere a uma modificação de código onde o desenvolvedor propositalmente modifica, ouintenciona modificar, o consumo de energia (ou a dissipação de potência) de um sistema outorna mais fácil para que outros desenvolvedores ou usuários finais possam fazê-lo. Nós entãoaplicamos sobre esses commits um método de análise qualitativa para extrair padrões recorrentesde informação e para agrupar os commits que intencionam reduzir o consumo energético emcategorias. Uma pequena pesquisa também foi realizada com os autores dos commits para avaliara qualidade da nossa análise e para expandir nosso entendimento sobre as modificações.

Nós também consideramos diferentes aspectos dos commits durante a análise. Obser-vamos que a maioria das modificações (~47%) ainda se aplicam às mais baixas camadas desoftware, isto é, kernels e drivers, enquanto que mudanças a nível de aplicação compreendem~34% do nosso conjunto de dados. Nós notamos que os desenvolvedores nem sempre estãoseguros do impacto de suas modificações no consumo de energia antes de realizá-las, em nossoconjunto de dados identificamos várias instâncias de modificações (~12%) em que os desen-volvedores demonstram sinais de incerteza em relação à eficácia de suas mudanças. Tambémapontamos alguns dos possíveis atributos de qualidade de software que são favorecidos em detri-mento do consumo de energia. Entre essas, destacamos alguns commits onde os desenvolvedoresrealizaram uma modificação que impactaria negativamente no consumo de energia com o intuitode consertar algum problema existente no software.

Também achamos interessante ressaltar um grupo específico de modificações quechamamos de “interfaces energy-aware”. Elas adicionam controles no software em questão que

Page 8: Por Irineu Martins de Lima Moura - UFPE...Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring

possibilitam outros desenvolvedores ou usuários finais a ajustar o consumo de energia de algumcomponente subjacente.

Palavras-chave: Mineração de Repositório de Software. Consumo de Energia. GitHub

Page 9: Por Irineu Martins de Lima Moura - UFPE...Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring

Abstract

Energy consumption has been gaining traction as yet another major concern that main-stream software developers must be aware of. It used to be mainly the focus of hardwaredesigners and low level software developers, e.g., device driver developers. Nowadays, however,mostly due to the ubiquity of battery-powered devices, any developer in the software stack mustbe prepared to deal with this concern. Thus, to be able to properly assist them and to provideguidance in future research it is crucial to understand how they have been handling this matter.

This thesis aims to aid in this regard by exploring a set of software changes, i.e., commits,to obtain insights into actual solutions implemented by open source developers when dealingwith energy consumption. We use as our main data source GITHUB, a source code hostingplatform for collaborative development, and extract a sample of the available commits acrossseveral different projects. From this sample, we manually curate a set of energy-aware commits,that is, any commit that refers to a source code change where developers intentionally modify,or aim to modify, the energy consumption (or power dissipation) of a system or make it easierfor other developers or end users to do so. We then apply a qualitative research method toextract recurring patterns of information and to group the commits that intend to save energyinto categories. A small survey was also conducted to assess the quality of our analysis and tofurther expand our understanding of the changes.

During our analysis we also cover different aspects of the commits. We observe that themajority of the changes (~47%) still target lower levels of the software stack, i.e., kernels, driversand OS-related services, while application level changes encompass ~34% of them. We noticethat developers may not always be certain of the energy consumption impact of their changesbefore actually performing them, among our dataset we identify several instances (~12%) ofcommits where developers show signs of uncertainty towards their change’s effectiveness. Wealso highlight the possible software quality attributes that may be favored over energy efficiency.Notably, we spot a few instances of commits where developers performed a change that wouldnegatively impact the energy consumption of the system in order to fix a bug.

It is also worth noting, we draw attention to a specific group of changes which we call"energy-aware interfaces". They add tuning knobs that can be used by developers or end users tocontrol the energy consumption of an underlying component.

Keywords: Software Repository Mining. Energy-Aware. GitHub

Page 10: Por Irineu Martins de Lima Moura - UFPE...Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring

List of Figures

2.1 Methodology flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.2 Commits default analysis view . . . . . . . . . . . . . . . . . . . . . . . . . . 322.3 Commits discussion view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322.4 Coding view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332.5 Survey analysis view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.1 Monthly number of energy-aware commits . . . . . . . . . . . . . . . . . . . . 43

Page 11: Por Irineu Martins de Lima Moura - UFPE...Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring

List of Tables

2.1 Commits classification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.2 Email survey numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.1 Energy-aware set changes statistics . . . . . . . . . . . . . . . . . . . . . . . . 353.2 Approaches that developers use to save energy . . . . . . . . . . . . . . . . . . 363.3 Number of energy-aware commits per stack level . . . . . . . . . . . . . . . . 433.4 Hedging commits changes statistics . . . . . . . . . . . . . . . . . . . . . . . 443.5 Quality attributes favored over energy-consumption . . . . . . . . . . . . . . . 483.6 Survey energy saved answers . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Page 12: Por Irineu Martins de Lima Moura - UFPE...Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring

List of Acronyms

LOC Lines of Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

DVCS Distributed Version Control System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

DVFS dynamic voltage and frequency scaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Page 13: Por Irineu Martins de Lima Moura - UFPE...Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring

Contents

1 Introduction 151.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151.2 Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161.3 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171.4 Organization of the Dissertation . . . . . . . . . . . . . . . . . . . . . . . . . 18

1.4.1 Note on commits citation . . . . . . . . . . . . . . . . . . . . . . . . . 18

2 Methodology 192.1 Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.2 Git and GitHub . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.3 Data Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.3.1 Sampling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.3.2 Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.3.2.1 Unavailable commits . . . . . . . . . . . . . . . . . . . . . 232.3.2.2 Duplicates . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.3.3 Observing and classifying . . . . . . . . . . . . . . . . . . . . . . . . 242.3.3.1 Software stack level . . . . . . . . . . . . . . . . . . . . . . 272.3.3.2 Hedging . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.3.4 Surveying . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282.4 Qualitative Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2.4.1 Analysis exclusion criteria . . . . . . . . . . . . . . . . . . . . . . . . 302.5 Analysis Graphical User Interface . . . . . . . . . . . . . . . . . . . . . . . . 31

3 Study Results 343.1 Energy-Aware Set Description . . . . . . . . . . . . . . . . . . . . . . . . . . 343.2 RQ1 What types of solutions do developers employ with the intent of saving

energy? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.2.1 Energy bug fix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.2.1.1 Preventing low power [No-sleep Bug] . . . . . . . . . . . . 363.2.1.2 Reducing wake ups . . . . . . . . . . . . . . . . . . . . . . 363.2.1.3 Preventing resource leak . . . . . . . . . . . . . . . . . . . . 373.2.1.4 Reducing excessive work . . . . . . . . . . . . . . . . . . . 373.2.1.5 Stopping endless computation [Loop Bug] . . . . . . . . . . 373.2.1.6 Other . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.2.2 Frequency and voltage scaling . . . . . . . . . . . . . . . . . . . . . . 37

Page 14: Por Irineu Martins de Lima Moura - UFPE...Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring

3.2.3 Disabling components . . . . . . . . . . . . . . . . . . . . . . . . . . 383.2.3.1 Context-aware disabling . . . . . . . . . . . . . . . . . . . . 383.2.3.2 Inefficient disabling . . . . . . . . . . . . . . . . . . . . . . 383.2.3.3 Unnecessary disabling . . . . . . . . . . . . . . . . . . . . . 393.2.3.4 Unconditional disabling . . . . . . . . . . . . . . . . . . . . 39

3.2.4 Using efficient component . . . . . . . . . . . . . . . . . . . . . . . . 393.2.5 Managing periodic work . . . . . . . . . . . . . . . . . . . . . . . . . 393.2.6 Low power idling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403.2.7 Timing out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403.2.8 Miscellaneous and Outliers . . . . . . . . . . . . . . . . . . . . . . . . 40

3.2.8.1 Lazy initialization . . . . . . . . . . . . . . . . . . . . . . . 403.2.8.2 Improving performance . . . . . . . . . . . . . . . . . . . . 413.2.8.3 Tuning display brightness . . . . . . . . . . . . . . . . . . . 413.2.8.4 Removing debugging . . . . . . . . . . . . . . . . . . . . . 413.2.8.5 Stalling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413.2.8.6 Environment change . . . . . . . . . . . . . . . . . . . . . . 413.2.8.7 Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413.2.8.8 Reducing memory access overhead . . . . . . . . . . . . . . 423.2.8.9 Input validation . . . . . . . . . . . . . . . . . . . . . . . . 423.2.8.10 Managing pins . . . . . . . . . . . . . . . . . . . . . . . . . 423.2.8.11 Packing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

3.3 RQ2 How are the energy-aware changes distributed across the software stack? 423.4 RQ3 To what extent are software developers certain of the energy consumption

impact of their changes? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443.5 RQ4 What software quality attributes may be given precedence over energy

consumption? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463.5.1 Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463.5.2 Responsiveness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463.5.3 Correctness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473.5.4 No actual savings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473.5.5 Miscellaneous . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

3.6 Developers Survey . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483.6.1 Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

3.7 Further Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493.7.1 Energy-Aware Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . 493.7.2 Context-aware energy saving . . . . . . . . . . . . . . . . . . . . . . . 503.7.3 Mobile Environment and Android . . . . . . . . . . . . . . . . . . . . 503.7.4 High number of soft-duplicates . . . . . . . . . . . . . . . . . . . . . 503.7.5 Power efficient workqueue . . . . . . . . . . . . . . . . . . . . . . . . 51

Page 15: Por Irineu Martins de Lima Moura - UFPE...Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring

14

3.7.6 Energy-Aware Source Code Review . . . . . . . . . . . . . . . . . . . 513.8 Threats to Validity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

3.8.1 Internal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513.8.2 External . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

4 Conclusion 544.1 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564.3 Other contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

References 58

Appendix 63

A Queries 64A.1 First phase sampling query . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64A.2 Second phase sampling query . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

B Scripts 68B.1 Availability checking script . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68B.2 Duplicate detection script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

C Surveys 72C.1 First phase survey email template . . . . . . . . . . . . . . . . . . . . . . . . . 72C.2 Second phase survey email template . . . . . . . . . . . . . . . . . . . . . . . 73

D Commits 75

Page 16: Por Irineu Martins de Lima Moura - UFPE...Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring

151515

1Introduction

1.1 Motivation

Thanks to the diversification of modern computing platforms, battery-driven devicessuch as smartphones, tablets and unwired devices in general are now commonplace in our lives.However, such devices are energy-constrained, as they rely on limited battery power supply.Energy consumption directly affects the perception of users about their quality. For example, ina survey conducted with more than 3,500 respondents from 4 different countries (Cat Phones,2013), long-lasting battery life has been cited as the most desired feature in a new phone by71% of the respondents. Likewise, recent research pointed out that battery usage is a key factorfor evaluating and adopting mobile applications (WILKE et al., 2013). As a result, not onlyresearchers (HAO et al., 2013; ZHANG; HINDLE; GERMAN, 2014; ZHUANG; KIM; SINGH,2010), but also giants of the software industry (GOOGLE, 2015; THEGUARDIAN, 2015) haverecently started to promote energy-efficient systems.

Traditionally, energy optimization research has focused at the hardware-level (e.g., (DAVIDet al., 2010; HOROWITZ; INDERMAUR; GONZALEZ, 1994)) and at the system-level (e.g., (FARKASet al., 2000; RIBIC; LIU, 2014)). Arguably, the strategy of leaving the energy optimization issueto lower-level systems and architecture layers has been successful. The main advantage of thisapproach is that user applications can be seen as black-boxes, i.e., no prior knowledge of theapplication source code or its behavior needs to be used to achieve better energy savings.

However, applications also impact energy consumption, although software itself does notconsume energy. When one energy-inefficient piece of code is introduced in a system comprisinghardware and software components, compilers and runtime systems cannot help much, sincethey are not aware of the semantics of the program. Unlike performance, where more efficient isalways better, sometimes an application will purposefully consume more energy to provide itsintended functionality, e.g., by activating an energy-intensive device.

In contrast, energy consumption bottlenecks often stem from inappropriate designchoices, as is often the case with performance bugs (JIN et al., 2012). Finding and fixingthese problems requires human insight. It is not always clear for programmers, however, what

Page 17: Por Irineu Martins de Lima Moura - UFPE...Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring

1.2. OBJECTIVE 16

they can do from a software engineering perspective to save energy. There seem to be miscon-ceptions and lack of appropriate tools (PINTO; CASTOR; LIU, 2014a).

Recent work (LI; HALFOND, 2014; KWON; TILEVICH, 2013; PINTO; CASTOR,2014; PINTO; CASTOR; LIU, 2014b; WAN et al., 2015) has shown that there is ample oppor-tunity to improve energy consumption at the application level. As an example, upgrading theConcurrentHashMap class available in Java 7 to its improved successor, available in Java8, can yield energy savings of 2.19x (PINTO; CASTOR, 2014). Nevertheless, developing anenergy-efficient system is a non-trivial task. Even though researchers have made great strides inempirical studies aiming to understand the impact of different program characteristics in energyconsumption (e.g., (LI; HALFOND, 2014; PINTO; CASTOR; LIU, 2014b; SAHIN; POLLOCK;CLAUSE, 2014; ZHANG et al., 2012)), these studies do not cover a complete range of languageconstructs and implementation choices. Therefore, developers still do not fully understandhow their source code modifications will impact energy consumption (PINTO; CASTOR; LIU,2014a).

In spite of this grim scenario, many energy-efficient systems are being developed inpractice. Starting from this premise, in this thesis we focus on a timely but overlooked question:

� How are software developers changing their code in ways that possibly affect theenergy consumption of systems?

1.2 Objective

In this work we aim to identify different aspects of the actual changes performed by open-source developers when impacting the energy consumption footprint caused by their software.With this intent, we collect a sample of commits from GITHUB and manually analyze and classifythem in order to be able to answer questions like:

� What are the different types of commits that are likely to modify a software systemenergy consumption?

� What types of solutions do developers employ with the intent of saving energy?

� How are the changes distributed across the software stack?

� To what extent are software developers certain of the energy consumption impact oftheir changes?

� What software quality attributes may be given precedence over energy consumption?

Besides these questions, we also seek to discover new items that could lead to future researchesin this field. Additionally, we are interested in knowing whether the changes had the desiredeffect and how the developers came to the conclusion of it. In this regard, we also survey thecommit authors to receive their direct feedback regarding the changes.

Page 18: Por Irineu Martins de Lima Moura - UFPE...Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring

1.3. CONTRIBUTIONS 17

1.3 Contributions

We believe that the main contributions of this work are:

� The definition of an energy-aware commit and the discovery of a specific type offunctionality that we call energy-aware interfaces.

� A list of seven most common themes that relate to how developers change softwareto improve energy consumption. This list cover themes like “Energy bug fix”, “Fre-quency and voltage scaling”, “Disabling components”, “Using efficient component”,“Managing periodic work”, “Low power idling” and “Timing out”. We also brieflypresent some less common approaches.

� In particular, we show that energy bugs are common and that developers are quiteconcerned with fixing them, 72 (16.78%) of the commits that show an energy-savingintention attempt to fix such issues. This number motivates further research on theidentification and correction of these bugs.

� Solutions based on traditional approaches such as frequency scaling and exploringmultiple levels of idleness are also common, covering 16.32% of the analyzed commitand 8.47% of our dataset.

� We show that the majority of the energy-aware changes (47.09%) are still targetinglower levels of the stack, although application level changes seem to have beenincreasing over the years

� We found that ill-chosen energy saving techniques can impact on the correctness ofthe application. 8 energy-aware commits warn about this.

� Developers are not always certain about the impact of source code modifications inenergy consumption. 96 commit messages included hedging cues suggesting that theGITHUB contributors were not entirely sure about their effects. We also identified48 reverted commits and contradictions between the developers in GITHUB commitdiscussions. Additionally, 23.53% of the survey answers regarding energy-savingcommits stated that they never actually measured the impact while 22.06% werehesitating when they said that the change had the desired effect.

� Even for systems where energy efficiency is critical, developers sometimes knowinglyapply modifications that will have a negative impact on energy efficiency in orderto balance trade-offs. We identified 89 commits documenting these situations. Incontrast with the hedging commits, this result suggests that some developers have astrong grasp over energy consumption-related solutions.

Page 19: Por Irineu Martins de Lima Moura - UFPE...Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring

1.4. ORGANIZATION OF THE DISSERTATION 18

� Lastly, all data used and generated by this study is made available on-line to motivateand enable further research on energy-aware commits.

1.4 Organization of the Dissertation

The remainder chapters in this thesis are organized in the following manner:

� Chapter 2 describes in detail the methodology used to conduct the research and givessome small background necessary to understand it;

� Chapter 3 presents the analysis results and discuss some of our findings;

� Chapter 4 summarizes our contributions, discusses related works and presents possi-ble venues for future research.

Lastly, the appendices for this thesis are structured as follows:

� Appendix A contains the search queries used to sample the commits;

� Appendix B contains the main scripts used to manipulate our dataset;

� Appendix C contains the survey templates used for the survey conducted with thecommit authors.

1.4.1 Note on commits citation

Since we are analyzing commits, on many occasions we will need to cite them. Todifferentiate a normal citation from a commit citation, when referring to commits we use thefollowing notation: [{PARTIAL_COMMIT_ID}], e.g., [C0].

Page 20: Por Irineu Martins de Lima Moura - UFPE...Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring

191919

2Methodology

This chapter describes the methodology used in this work to answer our research ques-tions. They are defined as:

RQ1. What types of solutions do developers employ with the intent of saving energy?

RQ2. How are the energy-aware changes distributed across the software stack?

RQ3. To what extent are software developers certain of the energy consumption impact oftheir changes?

RQ4. What software quality attributes may be given precedence over energy consumption?

Since this is an exploratory research, naturally in Chapter 3 we also discuss otherinteresting findings that we observed along the conducted analyses.

2.1 Workflow

The work described in this thesis mainly followed a workflow composed of five steps:(1) sampling the commits, (2) filtering duplicates and unavailable ones, (3) classifying andmaking observations about them, (4) surveying the authors and (5) executing a qualitativeresearch method over commits that intended to save energy. These steps are described in detail inSection 2.3. However, steps 1 through 4 were performed twice in distinct phases and each phasetargeted two different samples. The first phase was an unguided, i.e., exploratory, phase where weconsolidated our research questions and formulated the “energy-aware commit” definition. Thisphase gave us the experience to tackle the second phase more objectively and in a much fastermanner. A high level visualization of the whole research workflow can be seen in Figure 2.1.Our final dataset, that contained the commits used in the analysis of step 5, was composed of theresults of the two phases. When describing these steps in Section 2.3 we make the appropriatedistinctions between the two phases where needed.

Page 21: Por Irineu Martins de Lima Moura - UFPE...Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring

2.1. WORKFLOW 20

Figure 2.1: Methodology flow

Page 22: Por Irineu Martins de Lima Moura - UFPE...Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring

2.2. GIT AND GITHUB 21

2.2 Git and GitHub

Before describing our methodology, we must first give some background information ontopics related to GIT and GITHUB to facilitate the understanding of our methods.

GIT is a Distributed Version Control System (DVCS), i.e., a source code versioningsystem that enables code sharing without the requirement of a centralized repository. In GIT,every developer has his own copy of a repository and common source code versioning commandslike submitting a change or checking out a new branch is performed within the developer’srepository. When a developer submits a new change to his local repository, i.e., commits,GIT records several different types of metadata associated with the commit like: (1) a commitmessage provided by the developer to help understanding the change being introduced; (2) nameand e-mail address of the author of the changes and the date of authoring; (3) name and e-mailaddress of the committer of the changes1 together with the commit date; (4) a pointer(s) to theparent(s) of a commit; (5) a non-sequential id string that uniquely identifies the commit, alsoknown as commit hash or sha. GIT’s branching model is lightweight and promotes easy and fastcreation and manipulation of development branches. Once a work on a branch is done, it can bemerged into another branch to bring the changes from the former into the latter. Another moreadvanced form of changes sharing between branches is called rebasing. In a rebase GIT triesto reapply the changes from one branch into another in a way that the final result would like asif the branches had never diverged, unlike in normal merges where the GIT history will clearlyshow the point of convergence between the branches. When rebases are performed, GIT tries tokeep the author information intact, but other metadata like committer info, commit date and hashid are changed. In fact, any time a GIT command requires changing metadata of a commit, anew commit is created and such metadata is altered. To share source code, developers must firstclone other developers repositories and afterwards they may start sharing by pulling changesfrom and pushing changes to each other’s repositories.

GITHUB is a collaborative development service that has built many of its features aroundGIT. It has several tools and APIs that help in distributed development of software in general.Expanding on the easy branching model of GIT, GITHUB allow developers to share code througha “fork & pull” model (KALLIAMVAKOU et al., 2014). In this model, developers use aGITHUB feature called fork to create a clone of the project they desire to contribute to (theparent project) and when they are ready to share their modifications they may do so through pull

requests. Pull requests, as it names implies, invite developers in another repository to pull thechanges from the requesting developer’s repository. To promote collaboration, GITHUB alsoenables quick visualization of commit data through its web interface. In this interface, it is

1GIT makes the distinction between author and committer (CHACON, 2009), the former is the person whooriginally contributed the changes to the source code while the latter is the one who is creating the commit, that is,introducing the changes in the repository/branch. For example, when commiter C is creating a commit based on thecommit of author A, in the metadata of C’s commit, A would be the author and C would be the committer. However,for GITHUB repositories, most of the time they are the same (KALLIAMVAKOU et al., 2014)

Page 23: Por Irineu Martins de Lima Moura - UFPE...Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring

2.3. DATA COLLECTION 22

possible to view the general commit metadata stored by GIT as well as the differences introducedby the changes performed in the source code. This interface also allows developers to createthreads of discussions within a commit to enable sorting out any possible issues or questionsregarding the commit in question.

2.3 Data Collection

2.3.1 Sampling

In order to start our investigation, we decided to select our dataset based on the con-tents of the commit messages. Usually this is the place where programmers express theintention of a source code modification. However, neither GITHUB web interface nor itsweb API2 provide means for globally querying commit messages, i.e., to query over all com-mits over all GITHUB repositories. Instead, we had to resort to a proxy and we chose to useGITHUBARCHIVE (GRIGORIK, 2015). According to their website, it is “a project to recordthe public GITHUB timeline, archive it, and make it easily accessible for further analysis”.The archive is updated every hour and its dataset is available since February, 2011. As theirdescription implies, they record events that happen in GITHUB. Examples of such events can be:the creation of a new fork, publishing a comment in a bug report or, of our most interest, a push

event. Push events are created when contributors of a project push their changes to GITHUB,such events contain some metadata about the commit, e.g., the commit message and hash id, andpointers to access the whole commit information. GITHUBARCHIVE exposes this data through aweb tool3 that enables querying and exporting query results. By using this tool, we were ableto query the commit messages of any open-source project available in GITHUB that has everreceived a commit since 2011. We performed a query to select commits that are most likelyto be related to energy consumption. In the first phase of this research, our query searched forcommit messages that contained some specific terms used with the keywords energy and power.These terms were: *energy consum*, *energy efficien*, *energy sav*, *save energy*, *powerconsum*, *power efficien*, *power sav* and *save power*. The character “*” in each termworks as a wildcard: the query will select commits with messages that match at least one of theseterms, regardless of the beginning or the end of the message content. These terms were derivedfrom a previous work (PINTO; CASTOR; LIU, 2014a). For the second phase, we used thesesame terms, but instead exchanging the keyword for the word battery, i.e., *battery consum*,*battery efficien*, *battery sav*, *save battery*. This was motivated by previous experiences ofthis thesis author with the mobile environment where the word “battery” seems to be used as asynonym for energy. We also tried simple keywords searches like ”energy”, ”power” or ”battery”,

2In theory we could exhaustively search for each commit on each repository hosted in GITHUB using the API,however such option is not feasible due to the sheer amount of data that would have to be processed and also becauseGITHUB imposes a limit on the number of requests that may be performed within a single hour.

3https://bigquery.cloud.google.com/table/githubarchive:github.timeline

Page 24: Por Irineu Martins de Lima Moura - UFPE...Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring

2.3. DATA COLLECTION 23

but a search like this resulted in over 200,000 commits being selected, which would prevent usfrom conducting a mostly manual study. Considering the combined samples, we selected a totalof 3993 items, 2189 resulting the from energy/power keywords query and 1804 resulting fromthe battery keyword query. They span the time range between 12/03/2012 through 15/05/2014.Both queries can be found in Appendix A.

The sampled data was loaded to a Google Spreadsheet4. This spreadsheet was usedthroughout the entire research to keep track of the commits during the anlyses described insections 2.3.3 and 2.4. Any data data resulting from these analyses was properly codified andkept in specific columns to enable quick filtering, grouping and even further analyses.

It is important to stress out that each element (row) in our sample actually refers to apush event to GITHUB. Nonetheless, since each push event is always related to an actual commitwe shall indiscriminately call them commits, unless where the differentiation is made necessary(sections 2.3.2.1 and 2.3.2.2). We also note that, due to limitations of the services we used, notall public commits pushed to GITHUB were sampled. This is better explained in Section 3.8.

2.3.2 Filtering

After sampling the GITHUBARCHIVE database, we felt the need to filter out some of thedata since we observed several instances of unavailable and duplicate commits.

2.3.2.1 Unavailable commits

As mentioned in Section 2.3.1, the GITHUBARCHIVE database stores events of theGITHUB public timeline and these events contain partial information about the commits andpointers to the commits in GITHUB. If a commit becomes unavailable in GITHUB, this informa-tion is not reflected in the GITHUBARCHIVE database and therefore, when we sample, we mayend up selecting some these unavailable commits.

To detect and quickly discard such commits, we built a script that scans our entire datasetand tries to fetch the commit page on GITHUB. If the script fails to fetch the page after a coupleattempts, it marks the commit as unavailable and we do not consider it any further. Some of thereasons that explain why commits become unavailable might be:

� the commit project could have been removed by its owner5

� the project owner could have left GITHUB6

� the branch(es) to which the commit belonged was(were) removed

� the commit project could have been disabled by the GITHUB staff7

4https://docs.google.com/spreadsheets/u/0/5https://help.github.com/articles/deleting-a-repository/6https://help.github.com/articles/deleting-your-user-account/7https://help.github.com/articles/dmca-takedown-policy/

Page 25: Por Irineu Martins de Lima Moura - UFPE...Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring

2.3. DATA COLLECTION 24

We also directly asked the GITHUB staff if there is another reason for “unreachable commits”, andthey answered that “We don’t periodically gc repositories, however we do run gc on repositorieson request from an owner of the repository, which would be the reason for unreachable commits”8

Initially, we ran this script to filter out most of the unavailable commits so that we didnot have to waste time trying to visualize them on GITHUB. Afterwards, during the course of theresearch, we noted that some of the commits continued to become unavailable and therefore wedecided to periodically run the script to always have the latest availability status for each commitand to avoid referencing non-available commits in this document. Considering that this is also athreat to the validity of such studies, in Section 3.8.2 we explain how we have dealt with thisissue. Up to the time of thesis writing a total of 1247 commits in our overall sample were notavailable anymore. The availability checking script can be found in Appendix B.

2.3.2.2 Duplicates

The data sampled from the GITHUBARCHIVE database contained several duplicatecommits. These commits had the same hash id and/or the same commit message. We believe thishappens because (1) the exact same commit (same hash id) might be pushed to GITHUB morethan once, possibly from different repositories, or (2) due to GIT branch manipulation commands(see Section 2.2) actual copies of the commits were created and pushed. In either instance,each push would create a separate event in the GITHUBARCHIVE database and thus would beselected by our query. To filter out such commits and avoid unnecessary work, we created anotherscript that detects and marks such duplicates. This script considered any two given commitsas duplicates if they either had the exact same hash id or the exact commit message. In caseof the latter, we also tried to match other commit metadata like the total number of additionsand deletions, the author name and the changed file names. We believe this is required becausethere is a chance that short commit messages could cause false matches, that is, two differentcommits could have the same short message (e.g.,”power saving tweaks”). If the commits matchby hash id or by message together some other metadata, we unconditionally mark one of them asduplicate and disregard it for future analysis. For message-only matches, we decided to manuallyverify them. We verified 53 commits and found that 8 were misclassified. Overall our dataset has865 commits marked as duplicate. The duplicate selection script can be found in Appendix B.

2.3.3 Observing and classifying

After filtering, a team of three researchers manually analyzed the remaining commits.This team was composed of this thesis author, one former PhD student (Gustavo Pinto) andone current PhD student (Felipe Ebert). The aim of this analysis was (1) to identify whichcommits were actually related to energy-consumption and eliminate false-positives, (2) to gather

8The GIT gc command attempts to delete unreachable commits, i.e., commits without a branch or any otherpossible source of reference

Page 26: Por Irineu Martins de Lima Moura - UFPE...Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring

2.3. DATA COLLECTION 25

information9 required to answer our research questions ( RQ2 , RQ3 and RQ4 ) and (3) tomake observations about interesting items that may surface from the data. Initially the teammostly used the GITHUB web interface to read the commit message and to visualize the changesin the source code. In the second phase a set of UIs (Section 2.5) was primarily used for thisanalysis.

When first performing the classification during the first phase, the original goal was iden-tifying which commits were actually “related to energy consumption”. After some classificationswe then established the notion of an energy-aware commit described in Definition 1

Definition 1. Any commit that refers to a source code change where the developers intentionallymodify, or aim to modify, the energy consumption (or power dissipation) of the target system ormake it easier for other developers or end users to do so.

This definition was then applied to identify the energy-aware commits in our dataset.Once we identified an energy-aware commit, we would label it according to three possiblecategories:

� ENERGY-SAVING: The commit message or source code comments show a directintention to positively impact the energy consumption of the system;

� ENERGY-TRADEOFF: The commit message or source code comments acknowl-edge a negative impact in the energy consumption of the system or indicate theremoval of an energy saving feature/measure;

� ENERGY-AWARE INTERFACE: The commit message or source code commentsindicate that an energy-aware interface is being added or modified (see Definition 2)

During this same phase we also identified what we call energy-aware interfaces, their definitioncan be seen in Definition 2

Definition 2. Any functionality that provides tuning knobs for clients (e.g., developers orend-users) to control the energy consumption of an underlying component.

For example, they can be a new user-visible option to toggle energy saving modes ina smartphone. Another example is when developers add a boolean flag to allow the clients ofa class or method to decide when the component should use a more energy efficient option toperform its task. We discuss them more in Section 3.7.

In total we identified 826 energy-aware commits, 639 ENERGY-SAVING, 89 ENERGY-TRADEOFF and 98 ENERGY-AWARE INTERFACE.

Commits that did not fit in the energy-aware definition were considered false-positives.We note that, even though we consider primarily the commit message when classifying the

9During the first phase, the only task performed in this step was the energy-aware identification and classification,so to cover all aspects required to answer our research questions the researchers had to revisit the first phase commitsto collect the missing data, e.g., defining the stack level of a commit.

Page 27: Por Irineu Martins de Lima Moura - UFPE...Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring

2.3. DATA COLLECTION 26

commit, source code changes must also be available as we consider them a source of confirmation.Therefore, a commit message may show a clear intention to save energy, but still be considered afalse-positive because there are no visible changes, e.g., the commit just updates a release notesfile or only updates binary files. A total of 826 commits were marked as false-positive.

We also observed what we call ”soft-duplicate” commits, that is, commits that do notshare the same hash id nor the exact same message, but have rather similar message contents andsource code modifications. We believe that the reason for this is similar to the one explainedin Section 2.3.2.2 and is also related to the use of GIT’s branch manipulation commands (seeSection 2.2. For example, when rebasing or cherry-picking commits, the developer mightchoose to alter the commit message at his will. Another example is a special case of rebasecalled squashing, when using this command GIT will glob two or more commits together andautomatically copy the messages from each one into a single commit message, the final result isgenerally a bigger commit that shares parts of the changes and messages from the two (or more)previous commits. We disregarded 200 occurrences of commits with these characteristics. Insome special circumstances, the team was also unable to properly classify the commits becausethe commit message was poorly structured or contained ambiguous language in a way that theresearchers could not come up with an agreement. A total of 29 such unsure commits weremarked and not considered any further.

This manual commit review process was divided among the researchers. Each commitwas classified separately by at least two researchers and then the classifications were cross-checked. Any mismatch was thoroughly discussed and solved during online meetings betweenall members of the team. We conducted several of such meetings after the classification roundfor each phase.

Table 2.1 summarizes the number of occurrences of each type of commit in our sampleafter filtering, classification and the survey analysis (see Section 2.3.4). ENERGY-SAVING,ENERGY-TRADEOFF and ENERGY-AWARE INTERFACE encompass our set of enery-aware commits and from this point forth we shall use the term “energy-aware set” to identifythem. FALSE-POSITIVE refer to commits not considered energy-aware. DUPLICATE andNOT-AVAILABLE refer to commits that were automatically filtered by the duplicate and avail-ability detection scripts, respectively. SOFT-DUPLICATE refers to commits that were manuallyreviewed and considered duplicates. UNSURE refers to commits that could not be classified bythe authors.

As stated previously in this section, the researchers also collected other informationabout the commits during this analysis. For each commit we would determine the target softwarestack level (see Section 2.3.3.1) of the change and whether the commits showed any signs ofuncertainty when describing the energy consumption impact of the change (see Section 2.3.3.1).We would also add several different labels to the commits in the spreadsheet for any type ofinformation that captured our attention. For example, when we found a truly interesting changebecause of its novelty we would add an interesting label to the commit. In another cases, when

Page 28: Por Irineu Martins de Lima Moura - UFPE...Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring

2.3. DATA COLLECTION 27

Table 2.1: Commits classification

Classification Commits %ENERGY-SAVING 639 16.00ENERGY-TRADEOFF 89 2.23ENERGY-AWARE INTERFACE 98 2.45FALSE-POSITIVE 826 20.69DUPLICATE 865 21.66SOFT-DUPLICATE 200 5.01UNSURE 29 0.73NOT-AVAILABLE 1247 31.23TOTAL 3993 100

we spotted a piece of software related to a mobile environment we would we another specificlabel. This helped us to easily refer to these commits later on.

2.3.3.1 Software stack level

When answering RQ2 we considered the same software layer definition providedby (STALLINGS, 2011), which encompasses Operating System, Libraries/Utilities and Ap-plications. Operating System includes Kernels, Embedded Kernels, Drivers and Firmwares.Libraries/Utilities include scripts (general purpose scripts, building scripts and compile scripts)and embedded/non-embedded libraries. Application includes embedded applications, desktopapplication, and mobile applications. When assigning the corresponding software layer for eachcommit we based our judgements on the following characteristics: (1) the project description onGITHUB, (2) the files names, extensions and directory structure and (3) the changed source codeitself and (4) any related external documentation. The project description is the main decidingfactor since it usually describes the purpose of the software, however it is not always availableand in these circumstances we need to base ourselves in other characteristics. Files names,extensions and folder structure may also give information about the stack level, e.g., a driverrelated commit [C0] may change files inside a folder named “driver” or a commit to an Arduinoapplication may change files ending with an “.ino” extension [C2]. In the same manner, the codeitself provides contextual information about the stack level, e.g., changes to code conforming tothe same level may follow a given pattern or have certain similarities [C3, C4, C5].

2.3.3.2 Hedging

To answer RQ3 we considered the concept of hedging. It can be defined as the lackof commitment to the truth value of a proposition or a desire not to express that commitmentcategorically (HYLAND, 1998). In the Natural Language Processing field it is a synonym forlanguage that shows signs of uncertainty or speculation (SZARVAS, 2008; AGARWAL; YU,2010). Since a great deal of this work was manual labor, we used the guidelines provided by(VINCZE et al., 2008) to systematically look for hedges and take into account whether the

Page 29: Por Irineu Martins de Lima Moura - UFPE...Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring

2.3. DATA COLLECTION 28

commit message contained any hedges regarding the energy consumption impact of the change.These guidelines were used by linguistics to find instances of hedging within a corpus of Englishbiomedical texts and to annotate such instances with markers that define the scope of the hedging.They contain a list of hedging cues, i.e., common words or expressions that imply hedging (e.g.,“might”, “should”) as well as instructions for discovering more complex forms of hedges. Whilethe guidelines were meant to detect any instance of hedging within their target corpus documents,in this work we only consider hedges concerning the energy consumption impact, any otherhedging within the commit messages is disregarded.

2.3.4 Surveying

As a mean of confirming our assumptions about the analyzed commits and to gathersome more information about the changes, we devised an email survey that was sent out to thecommit authors. Since it was small enough, we decided to embed the questions within the emailmessage contents and we used templates to enable the customization of each message for eachauthor/commit pair. The author e-mail addresses were collected from the author field of theGIT commit (See Section 2.2). Just as was the case with other steps in the methodology flow(Figure 2.1), the survey was sent out twice, one for each sample analysis phase. However, for thesecond batch of e-mails, we decided to not include authors whose commits had already beenincluded in the first batch. We took this conscious precaution in an attempt to avoid jeopardizingthe authors view of this research and possible future researches since repetitive unsolicitede-mails can be viewed as spam. Another difference between the first and second batches is thatwe altered the templates to include the energy-aware commit definition and to be more specific inour questions, this was motivated by replies from the first batch that sometimes failed to addressour questions. The templates for the first and second phase batches can be seen in AppendixC. The survey contained questions to confirm the authors’ intentions (e.g., “Would you be able

to describe your intention when you performed this commit?”), to inquiry that the change hadthe desired effect in the system (e.g., “Did you notice any difference on energy consumption

footprint on the target system?”) and to know how the authors came to that conclusion (e.g.,“How did you observe that?”).

We used another Google Spreadsheet to keep track of the delivery status for each e-mailand to store codified information extracted from the survey answers. Overall 816 email attemptswere performed with 47 failing to deliver because the email address was invalid or unreachable.The remaining 769 e-mails were delivered to 583 authors10 and we received a total of 95 replies.87 of these replies fully or partially addressed our questions while 8 did not answer them. Forthese unanswered e-mails, the authors either simply refused to answer or they were unable toanswer because, as they acknowledged, the actual author of the commit was someone else. This

10Within each e-mail batch multiple e-mails were sent to the same author if the author had performed more thanone commit

Page 30: Por Irineu Martins de Lima Moura - UFPE...Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring

2.4. QUALITATIVE ANALYSIS 29

Table 2.2: Email survey numbers

Delivery status # e-mails (%) Reply status # e-mails (%) Answer status # e-mails (%)Undeliverable 47 (5.76%)

Delivered Unreplied 674 (82.60%)Unanswered 8 (0.98%)769 (94.24%)

Replied 95 (11.64%)Answered 87 (10.66%)

equates to a 10.66% answer rate. Table 2.2 summarizes all these numbers. In total we sente-mails for commits found in 648 different GITHUB repositories.

We refer to the survey information when presenting the results of our research questions,but we also discuss it separately in Section 3.6.

2.4 Qualitative Analysis

To answer RQ1 , once we have classified the commits, we select the ENERGY-SAVING ones and try to extract reliable information from the commit messages and thesource code using a qualitative approach named Thematic Analysis (BRAUN; CLARKE, 2006).Thematic analysis is a common qualitative analysis method that emphasizes examining andrecording themes within data. The application of this approach has six stages: familiarizationwith data, generating initial codes, searching for themes among codes, reviewing themes, definingand naming themes, and producing the final report. We explain how we conducted each one inthe remainder of this section. While being described separately here, the two first stages shownbelow were actually performed concomitantly with the commit classification step (Section 2.3.3).

1. Familiarization with data: Here the researchers analyzed the commit message andthe source code modification for each commit.

2. Generating initial codes: Each author gave a code for each analyzed commit. Thecode is an attempt to express the core of the modification. For instance, a commit thatadds a new DVFS (HOROWITZ; INDERMAUR; GONZALEZ, 1994), a techniquefor dynamic scaling CPU frequency, algorithm can be coded as “DVFS”. In this step,we also refined codes by combining and splitting potential codes.

3. Searching for themes: In this step, this thesis author tried to combine coded data toform an initial list of themes. When in doubt, the other researchers provided supportto find broader patterns within data.

4. Reviewing themes: At this stage, we have a potential set of themes. We then searchedfor data that supports or refutes our themes. For instance, we updated the theme of acommit that was initially themed as “DVFS” to “Frequency and voltage scaling”. In

Page 31: Por Irineu Martins de Lima Moura - UFPE...Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring

2.4. QUALITATIVE ANALYSIS 30

this commit, the programmer decreased the voltage of the display. This solution isrelated to voltage scaling but not to DVFS.

5. Defining and naming themes: Here we refined existing themes. At this time, most ofthe themes already had a name. However, we have renamed some of them to covercodes with small numbers of commits, otherwise we would have to discard them. Weestablished fifteen as a threshold for the minimum number of elements that a groupof code-related commits must have to be considered a separate theme. In a previouslypublished study (MOURA et al., 2015), we used five as the commit threshold. Thatstudy already covered a large number of commits (290) and only half of the themeswere actually discussed, here the number of commits is even greater (429) so wedecided to increase the threshold to reduce the number of themes generated andincrease our confidence on the ones on which we report. Since we are attempting toassign a single theme for each commit, commits with more than one energy-savingchange are considered in a separate Outlier theme.

6. Producing the final report: This process led to the elicitation of 7 main themes. Thesethemes are discussed in Section 3.2. Some of the commits without a proper themeare also discussed.

2.4.1 Analysis exclusion criteria

To avoid introducing unnecessary bias due to our lack of understanding of some of theproject domains, we take a conservative approach and do not analyze commits that do not passcertain criteria:

1. Generally we do not cover commits with too many changes (> ~1000 Lines ofCode (LOC)). The amount of modifications in these commits makes it quite hard tovisualize in the source code the ones that actually aim to save energy. However, insome instances, we did consider the commit if the message enabled us to quicklyperform a string search to spot the source code modification.

2. We also do not consider a commit suitable for analysis if (1) the message containsno description at all besides showing the energy saving intention, e.g., ”Tune for

battery life” [C6], or if (2) the message or source code comment only contains a literaldescription of the modification, e.g., ”reduce battery usage: RCU_ FAST_ NO_ HZ

= ON” [C7], with no rationale or background information about the change. Suchcommit messages contain barely any content that could be used for the qualitativeanalysis and understanding them would require knowledge of the software or thesoftware domain in question.

Page 32: Por Irineu Martins de Lima Moura - UFPE...Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring

2.5. ANALYSIS GRAPHICAL USER INTERFACE 31

3. Lastly, we also do not consider commits when none of the researchers could actuallymap the commit description to the source code change. This is usually the case forchanges that are too domain or software specific and require knowing particularitiesof the software in question.

We try to mitigate such commits through the survey presented in Section 2.3.4 and a total of9 commits previously not analyzed could be considered after the survey. Overall 210 commitswere excluded from this analysis. However, we do note that they were still taken into accountfor the other research questions. This left us with 429 commits that were then taken intoconsideration to answer RQ1 .

2.5 Analysis Graphical User Interface

The sheer amount of information in the Google Spreadsheet that was used to manage ourdataset made the already tiring task of manually analyzing the commits even more laborious.While performing certain tasks in the spreadsheet UI was certainly easy and straightforward,e.g., obtaining counts or filtering and comparing commits in a group, when analyzing individualcommits there was too much information noise of the neighboring rows (commits). Also,since the commit source code was not available in the spreadsheet and had to be viewed in theGITHUB website, there was a constant context switch between the spreadsheet and the commitpage on GITHUB.

To alleviate these issues, we decided to create graphical user interfaces customizedto our analysis tasks. We used these interfaces for individual commit analysis, for commitdiscussions among the researchers and also for the survey analysis. The interfaces were builtusing several web technologies and were hosted on Google App Script11 to allow direct accessto the spreadsheet contents. To give a perspective on the helpfulness of these interfaces it isinteresting to mention that the manual analysis of the initial dataset took over 3 months coveringnearly one thousand commits while the second analysis took less than a month also coveringnearly the same amount. We do not claim this as a hard truth about such UIs usefulness, but itis surely a point to be considered for future research. Samples of the used UIs can be seen inFigures 2.2, 2.3, 2.4 and 2.5

11http://www.google.com/script/start/12This view was mainly required because this thesis author had sent the survey through his email account and the

replies were bound to that account, not accessible by the other members of the team

Page 33: Por Irineu Martins de Lima Moura - UFPE...Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring

2.5. ANALYSIS GRAPHICAL USER INTERFACE 32

Figure 2.2: Commits default analysis view - This was the default view used during theclassification of the commits. On the top right corner there is a mask selection mechanismthat allows different visualization of the properties of a commit so that a user can focus on

specific properties when needed

Figure 2.3: Commits discussion view - This was the view used after the initialclassification of a dataset to discuss any disagreement or pending issue regarding the

commits

Page 34: Por Irineu Martins de Lima Moura - UFPE...Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring

2.5. ANALYSIS GRAPHICAL USER INTERFACE 33

Figure 2.4: Coding view - This view was used during the qualitative analysis to performthe coding steps

Figure 2.5: Survey analysis view - This view was used during the survey analysis tofacilitate visualization of the email contents among all researchers12

Page 35: Por Irineu Martins de Lima Moura - UFPE...Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring

343434

3Study Results

In this chapter we present the results of the analyses described in Chapter 2. We start byhighlighting some numbers of our energy-aware set (Section 3.1). Then we present the resultsfor our research questions (Sections 3.2, 3.3, 3.4 and 3.5) and in Section 3.6 we briefly discussthe survey results. Lastly we provide some further discussions on items in our dataset that weconsidered noteworthy (Section 3.7).

3.1 Energy-Aware Set Description

Our energy-aware set is composed of 826 commits. This number represents 20.69% ofour total sample and 0.0009% of the push events in the GITHUBARCHIVE database over thesampled time range. They were found in 659 different GITHUB repositories and were performedby 591 different authors1. We found a total of two outstanding authors, together they performed atotal of 34 commits (19 and 15 each) which is equivalent to 4.12% of our entire energy-aware set.Analyzing the commits of one these top authors, we observed that they greatly differ betweeneach other in terms of the intention used to save energy. For instance, they vary from (1) changesto tweak governor parameters [C14], to (2) disable a feature when the display is turned on [C15]and to (3) directly reduce an LCD display voltage [C16]. This same author also performedcommits to revert a previous energy-saving tweak due to issues that it introduced [C17] and toadd an energy-aware interface [C18].

Of the 659 repositories, 208 are forks of some other repository and the other 451 are baserepositories2. In average they have 5,83 branches (SD: 7,12; Median: 3). The most common toplanguages in these repositories are, in this order, C, Java and C++. The GITHUB repository thatcontained the most commits is RAZR-K-Devs/android_kernel_motorola_omap4-common, with14 energy-aware commits. This is a Kernel project based on Motorola 3.0.8 Android Kernel.The energy-awareness here also varied greatly. For instance, some commits were performed withthe intention to (1) select different energy-efficient governors [C19], to (2) improve an existing

1We count as an author the e-mail address contained in the GIT commit author field2By fork here we mean repositories that were created using the GITHUB forking feature, in reality many of the

repositories in our energy-aware set are some branched off version of the Android code base (Section 3.7.3)

Page 36: Por Irineu Martins de Lima Moura - UFPE...Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring

3.2. RQ1 WHAT TYPES OF SOLUTIONS DO DEVELOPERS EMPLOY WITH THEINTENT OF SAVING ENERGY? 35

Table 3.1: Energy-aware set changes statistics

Statistic Changes Files touchedMean 377,79 4,86Median 35 2Mode 2 1SD 2.256,37 11,63Max 52.124 171Min 1 1

governor implementation [C20], and to (3) add an energy-saving option (energy-aware interface)based on the screen state [C21]. This shows that the same software application can benefit fromdifferent energy-aware optimizations. Other than this project, 3 other projects have between 6 to8 energy-aware commits each. 13 projects have between 4 to 5 energy-aware commits each, andthe remaining ones have less than 4 energy-aware commits each.

Regarding the commit sizes, Table 3.1 summarizes the changes3 statistics. We can seethat they range from very small (1 change only) to unusually large (52,124 changes) and thenumber of files changed goes from just 1 to 171 files (surprisingly, not the same commit asthe one with the largest number of changes). We can see that at least 50% of them performed35 changes or less in total and touched only two file or less. A caveat must be made wheninterpreting commit change numbers: a commit may include (and actually in many circumstancesdoes include) several unrelated changes.

3.2 RQ1 What types of solutions do developers employ withthe intent of saving energy?

This research question aims to elucidate how practitioners are actually changing theirsoftware to improve energy consumption of their systems. After the exclusion criteria describedin Section 2.4.1, we considered a total of 429 commits. From these commits we derivedseven themes which we introduce in the following sections. For some themes we also present alist of sub-themes. Changes that did not fit in a group of fifteen or more commits were groupedunder the Miscellaneous theme. In the Outliers theme we grouped changes that contained two ormore energy saving approaches. We discuss the most outstanding ones of both of them briefly.

We note that in some theme names we use the term component, in these circumstancesit can mean both a hardware component, e.g., a sensor, a display, a Wi-Fi interface, etc; or asoftware component, e.g., a service, an UI element, a library or a whole feature. When discussingthese themes we try to show examples for both cases if applicable.

Table 3.2 summarizes the approaches that developers use. The theme with the largest

3GITHUB counts line updates as one deletion plus one addition, therefore the total number of changes does notnecessarilly equal to the number of lines updated

Page 37: Por Irineu Martins de Lima Moura - UFPE...Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring

3.2. RQ1 WHAT TYPES OF SOLUTIONS DO DEVELOPERS EMPLOY WITH THEINTENT OF SAVING ENERGY? 36

Table 3.2: Approaches that developers use to save energy

Theme # commits %Energy bug fix 72 16.78Frequency and voltage scaling 70 16.32Disabling components 43 10.02Using efficient component 36 8.39Managing periodic work 31 7.23Low power idling 16 3.73Timing out 15 3.50Miscellaneous 126 29.37Outliers 20 4.66

number of commits were Energy bug fix followed by Frequency and voltage scaling. Togetherthey add up to 142 commits which is equivalent to 33.10% of the analyzed commits.

3.2.1 Energy bug fix - 72 occurrences

This theme contains commits that fix “Energy Bugs”. An energy bug is: “an error in

the system, either application, OS, hardware, firmware or external, that causes an unexpected

amount of high energy consumption by the system as a whole” (PATHAK; HU; ZHANG, 2011).We consider a commit as an energy bug fix if the programmer clearly states in the commitmessage that it will fix an energy bug. We found several different types of energy bug fixes andhere we group them by sub-themes, some of these sub-themes have a corresponding name in thetaxonomy described by (PATHAK; HU; ZHANG, 2011) and we show this equivalent name inbrackets next to the sub-theme name.

3.2.1.1 Preventing low power [No-sleep Bug]

Commits in this sub-theme try to remove some undesired condition that is preventing adevice to go into a lower power mode. In commit [C49], for example, the developer inhibited aCPU always on two-core policy because it “prevented the device from entering deep sleep”. Wefound four instances of them.

3.2.1.2 Reducing wake ups

Similar to preventing low power, commits in this sub-theme try to reduce the number ofwake ups caused by an issue that continuously requires a device to come out of its low powermode more often than needed. We found nine of them. For example, commit [C50] reduces asampling interval because “Original implement(sic) will keep UE wake up every 12 minutes”.

Page 38: Por Irineu Martins de Lima Moura - UFPE...Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring

3.2. RQ1 WHAT TYPES OF SOLUTIONS DO DEVELOPERS EMPLOY WITH THEINTENT OF SAVING ENERGY? 37

3.2.1.3 Preventing resource leak

Resource leak is a well known type bug that can slowly deplete a system’s memory, butthey can also be the source of energy bugs. Eight energy bug fixes mention a solution to stopsome form of resource leak that was causing an abnormal increase in energy consumption. Forinstance, commit [C51] states as its cause “(long commit id) intruduces (sic) a bug where the ts

uart could not be closed correctly”.

3.2.1.4 Reducing excessive work

In this sub-theme the commits attempt to reduce some unwanted excessive computationor usage of a component. We found a total of five such commits and of note we cite [C52] thathides an UI element because under certain conditions it would cause “continuous buffer updates”that resulted in a “spike in power consumtion (sic)”.

3.2.1.5 Stopping endless computation [Loop Bug]

We grouped four commits in this sub-theme and they all attempted to fix an issue thatcaused a computation to never stop. For example, commit [C53] “remove infinite animation that

triggers continious (sic) style recalculation”.

3.2.1.6 Other

The remaining bug fixes (43) did not fit in a specific sub-theme and were grouped here.They either (1) did not specify the root cause of the issue, (2) were too domain specific or (3)did not have enough representatives to be grouped together within a sub-theme. Some goodexamples are: trying to fix an integer overflow that causes a higher than should be processorstate to be selected [C55]; fixing an incorrect port configuration that was causing the system touse more power than needed [C56]; or reducing the voltage of a component that was wronglyincreased in a previous commit [C57].

3.2.2 Frequency and voltage scaling - 70 occurrences

The second theme with the largest number of commits in our sample contained solutionsrelated frequency and voltage scaling. The key insight is that a lower frequency yields lowerpower consumption. Saving energy, however, is not the same of saving power, because areduction in frequency may increase the execution time. The challenge here is to figure outwhen the reduction in frequency is significant enough to cause performance degradation, thusnegatively impacting on energy saving. In our analysis, we observed that such manipulations canbe static or dynamic. In the static approach the programmer hard-codes a new frequency/voltagevalue directly in the source code. In the dynamic approach they are commonly using dynamicvoltage and frequency scaling (DVFS) techniques (PERING; BURD; BRODERSEN, 1998).

Page 39: Por Irineu Martins de Lima Moura - UFPE...Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring

3.2. RQ1 WHAT TYPES OF SOLUTIONS DO DEVELOPERS EMPLOY WITH THEINTENT OF SAVING ENERGY? 38Although frequency and voltage scaling became a popular technique to make CPU processorsmore energy-efficient, we have identified several commit authors who focused on peripherals.For instance, an author said that “Reduce Wifi voltage for power savings. Should be beneficial

for a wifi only device” [C87]. In such commit, the GITHUB contributor changed a singleline of code, updating a variable from .microvolts = 2000000 to .microvolts =

1800000. This commit used a static approach, that is, the author hard-coded a new voltagevalue.

Solutions using the dynamic approach are greatly diverse. For instance, DVFS offersthe chance to change the CPU frequency on the fly. DVFS algorithms, or “cpufreq governors”,dynamically decide what frequency should be used at a given time. We found several commitsfocused on using such DVFS features. They vary from (1) tuning existing governors [C88]or (2) setting a different governor as default [C89]. However, this approach hides importantperils. As discussed in recent literature (LIU; PINTO; LIU, 2015; KAMBADUR; KIM, 2014),well-established Linux governors do not provide effective energy savings. In the worse case,governors can even increase energy consumption, instead of reducing it.

3.2.3 Disabling components - 43 occurrences

In this theme the basic premise for the commits is to disable or stop components inan attempt to reduce energy consumption. We found four different situations in which suchdisabling happens and here we group the commits in sub-themes according to these situations.

3.2.3.1 Context-aware disabling

Commits in this sub-theme follow a similar pattern of “disable X when Y”, they generallyattempt to disable components when under certain system conditions that would render thecomponent usage unnecessary. Such conditions vary greatly and they can be, for example,(1) when an application is not in foreground [C74]; (2) when there is no network connectivityavailable [C75]; (3) when the screen is off [C76]; when not showing an UI element [C77].The components that are disabled when such conditions are met can be: (1) threads [C74]; (2)background services [C75, C76]; (3) GPS [C77]; (4) timers [C78].

3.2.3.2 Inefficient disabling

Here the commit authors attempted to disable components that they deemed energy-inefficient, even if that meant losing a feature. An example that we obtained from one of thesurvey responses was the disabling of a syntax highlighting plugin for a text editor that was “disk

and CPU heavy” [C64].

Page 40: Por Irineu Martins de Lima Moura - UFPE...Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring

3.2. RQ1 WHAT TYPES OF SOLUTIONS DO DEVELOPERS EMPLOY WITH THEINTENT OF SAVING ENERGY? 39

3.2.3.3 Unnecessary disabling

Unlike in the context-aware disabling sub-theme, here the commits perform changes tounconditionally disable components that are either unused or thought to be unnecessary. Commit[C65] turns off several hardware components not needed by the Arduino application in question.

3.2.3.4 Unconditional disabling

The remaining commits were grouped under this sub-theme. They mostly do not presentan explicit motivation or condition for disabling the component, but still show the intention todisable as a mean of achieving energy savings. A small example is commit [C66] which simplystates “Disable accelerometer and compass on Android to save battery.”

3.2.4 Using efficient component - 36 occurrences

The commits in this theme perform changes to use more efficient versions of certainlibraries or services, as well as more energy-efficient devices. We also include in this themecommits that make use of power saving mode, usually a black-box technique that does notrequire knowledge about how the energy saving is achieved. Examples in this category are: (1)using power efficient work queue [C80], (2) using a connectivity engine to provide enhancednetwork selection [C79], and (3) enabling a thermal framework to achieve energy savings [C81].Most of these energy savings components are offered by newer kernels (e.g., the power efficientworkqueue and the Thermal Framework), which greatly reduce the barrier for employing anenergy saving technique in low-level applications, since the programmer does not need to worryabout low-level implementation details, which are abstracted away in those libraries.

3.2.5 Managing periodic work - 31 occurrences

All the commits in this theme are in some form dealing with computations that happenperiodically or that only need to happen periodically. They either (1) decrease the frequency withwhich a given computation happens, (2) split a continuously running computation by introducingintervals or (3) remove a periodic computation that only needs to be executed on-demand.Examples for first case are commits that reduce the frequency of background scans [C67, C68,C69], the sampling rates of a sensor [C70] or the synchronization frequency of backgroundservices [C71]. For the second case we list [C72] that removes a continuously running servicein favor of performing the computation in intervals triggered via OS alarms. For the last casewe cite commit [C73] that removed a periodic feed update to only perform it when actuallyrequested by the system.

Page 41: Por Irineu Martins de Lima Moura - UFPE...Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring

3.2. RQ1 WHAT TYPES OF SOLUTIONS DO DEVELOPERS EMPLOY WITH THEINTENT OF SAVING ENERGY? 40

3.2.6 Low power idling - 16 occurrences

The general rule of thumb for commits in this theme is that the program, or a particularthread, should go to suspend/sleep/low power mode when idle. We also consider commits underthis theme if the modification changes an already in use low power mode for an even more energyefficient one or attempts to reduce energy consumption even further when idling in low power.The rationale behind this theme comes from the idea that sending the device to an idle statemight save energy. A common example is commit [C82] that puts the device in sleep mode whileno buttons are pressed. According to a recent study, idle states can be seen as complementary toother energy savings techniques, and can save up to 25% of energy consumption (KAMBADUR;KIM, 2014). However, there are at least two important concerns that the programmer shouldconsider when using this approach. First, putting threads in an idle state may require polling towake them up. Depending on the polling frequency, it might be a double-edged sword, increasingenergy consumption behind the scenes. Second, the frequency with which a thread is sent to anidle state, and then waken up, is also important. If this frequency is too high, it might increasethe energy consumption due to several changes of states.

3.2.7 Timing out - 15 occurrences

This theme covers commits that add, decrease or improve timeouts. Normally when atimeout happens a computation is stopped in an attempt to decrease the number of times that thecomputation is performed, however it can also be falling back to less energy-hungry option [C62].Time outs can be completely unconditional, i.e., “sleep after 120 sec” [C59] or based on someother additional factor like no activity detected, e.g., “turns off the relays if no movement isunder way and no movement commands have been sent” [C60]. Usually the computation iswrapped in a loop, which is continuously running until a threshold or a halt event is reached. Forinstance, the author of commit [C61] added a condition to explicitly stop a scanning loop after athree minutes timeout. According to the author, such condition makes sure that the scanning willstop regardless of an explicit request to stop it and therefore save energy.

3.2.8 Miscellaneous and Outliers - 146 occurrences

In this subsection we discuss some of the commits that could not fit to specific themes,but contained unusual or appealing solutions aimed at improving energy consumption.

3.2.8.1 Lazy initialization

Some commits attempt to take a lazy initialization approach. This means disablingcomponents by default and only enabling them when actually needed. One example is commit[C91], that disables the device network interfaces on application start up and only re-enablesthem when a location request is received.

Page 42: Por Irineu Martins de Lima Moura - UFPE...Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring

3.2. RQ1 WHAT TYPES OF SOLUTIONS DO DEVELOPERS EMPLOY WITH THEINTENT OF SAVING ENERGY? 41

3.2.8.2 Improving performance

A few commits performed modifications aimed at improving performance and, accordingto the commit messages, gain energy savings. For example, commit [C94] changes somemultiplication and division operations by bit shifting operations assuming that such changes willimprove performance and battery life. We highlight that better performance does not necessarilyimply less energy consumption (PINTO; CASTOR; LIU, 2014b; PINTO; CASTOR, 2014) andthat care must be taken when making such direct associations.

3.2.8.3 Tuning display brightness

We observed a couple commits tuning the display brightness of a device. They either (1)reduced the brightness [C95] under certain conditions, (2) reduced the minimum brightness limit[C96] or (3) used a more efficient algorithm for choosing brightness levels [C97]

3.2.8.4 Removing debugging

Some commits attempt to disable or remove logging and/or other debugging related fea-tures from the target software in an attempt to reduce consumption. For example, commit [C93]disables all the logging calls within a function by turning them in source code comments.

3.2.8.5 Stalling

Although CPU pipeline stalls are synonymous of performance bottlenecks, commit [C8]actually purposefully induced them during system idle loop. From the survey reply it came toour knowledge that the system in question did not have a low power mode/instruction for idlingand had to continuously keep looping when not performing any task. The author of the committhen introduced a division by zero instruction that would cause a stall. According to the author,such stalls dramatically reduce the processor power.

3.2.8.6 Environment change

Two commits perform a drastic change: they moved some computation to another, moreefficient, platform or environment. For example, commit [C54] rewrote a Ruby script in Node.jsbecause, according to the survey respondent, Node.js was “better at idling” than Ruby.

3.2.8.7 Caching

Caching, a common performance optimization, is also used with the intent of reducingenergy consumption. We found two commits in this regard. For example, one of them im-plemented a bitmap cache to improve UI responsiveness and reduce battery consumption of amobile application [C90].

Page 43: Por Irineu Martins de Lima Moura - UFPE...Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring

3.3. RQ2 HOW ARE THE ENERGY-AWARE CHANGES DISTRIBUTED ACROSS THESOFTWARE STACK? 42

3.2.8.8 Reducing memory access overhead

Another interesting commit [C86] in our dataset attempts to reduce consumption bytweaking computations that perform many memory accesses. According to the author of thecommit, who answered the survey, the changes simplify indexing calculations for memoryaccesses that happen on a dedicated graphics hardware.

3.2.8.9 Input validation

In commit [C84], the changes performed add checks to reject input parameters that falloutside specific thresholds for a device, the commit message states that using improper valuescould cause high energy consumption and poor performance.

3.2.8.10 Managing pins

This is a specific kind of commit in which the solutions are restricted to software thatcontrols embedded devices such as Arduino4 boards. Developers of such software have theability (and the responsibility) to manage low level hardware components up to the input andoutput ports of their boards. When they are trying to save energy, a good number of the solutionswe found revolve around setting the pins (or ports) in these boards to specific modes, usuallywhen the pin is not going to be used. A canonical example is commit [C58], which “Make all

pins inputs with resistors to minimize power consumption”.

3.2.8.11 Packing

The general idea of the commits in this group is to try running as many tasks or threadsas possible within a single processor core, i.e., packing them, and to avoid migrating tasks toother cores unless needed. According to one of the commits [C83], packing the tasks within acore will let other cores idle longer. We note that all the commits performing such modificationswere targeting an OS scheduler.

3.3 RQ2 How are the energy-aware changes distributed acrossthe software stack?

Traditionally energy consumption has been mainly focus of developers in the low levelsof the software stack, with researchers (ELLIS, 1999) urging for application level solutionseven before the recent mobile devices surge. In this RQ we want to get a sense on how thisassumption still holds.

Using the methodology described in Section 2.3.3.1 we gathered the numbers shown inTable 3.3. We can see that OS level changes still covers the majority of the commits encompassing

4https://www.arduino.cc/

Page 44: Por Irineu Martins de Lima Moura - UFPE...Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring

3.3. RQ2 HOW ARE THE ENERGY-AWARE CHANGES DISTRIBUTED ACROSS THESOFTWARE STACK? 43

Table 3.3: Number of energy-aware commits per stack level

Stack Level # commits %OS 389 47.09Libraries/Utilities 159 19.25Application 278 33.66

Figure 3.1: Monthly number of energy-aware commits between 05/2011 and 05/2014.One outlier from 2005 was excluded from the graph.

almost half of the energy-aware set, while application level changes represented 33.66% andlibraries and scripts 19.25% of them. This relative imbalance in number of commits is unfortunatebecause there is evidence that even better energy savings can be achieved by encouragingapplication developers to produce energy-aware software solutions (PINTO; CASTOR, 2014;PINTO; CASTOR; LIU, 2014b; KWON; TILEVICH, 2013). We believe that applicationdevelopers ought to seize more energy saving opportunities.

Although we are not using the mathematical rigor required to perform a trending analysis,we also find important to highlight an upwards looking tendency in the number of energy-awarecommits over the years. This can be seen in Figure 3.1 that shows the monthly number ofenergy-aware commits included in the time range we used for sampling. From the graph we cansee that the overall number of energy-aware commits has been increasing over the years and thatapplication level changes showed a steady increase compared to OS and Libraries. This mightmotivated by the crescent usage and offer of mobile applications (PEREZ, 2015; WARREN,2013; PEREZ, 2014). These results prompt us to do further analysis to confirm such trend.

Page 45: Por Irineu Martins de Lima Moura - UFPE...Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring

3.4. RQ3 TO WHAT EXTENT ARE SOFTWARE DEVELOPERS CERTAIN OF THEENERGY CONSUMPTION IMPACT OF THEIR CHANGES? 44

Table 3.4: Hedging commits changes statistics

Statistic Changes Files touchedMean 242,84 3,53Median 34,5 1Mode 4 1SD 681,16 5,42Max 5448 37Min 1 1

3.4 RQ3 To what extent are software developers certain ofthe energy consumption impact of their changes?

The lack of tools for developing energy-aware applications is well-known (e.g, (PINTO;CASTOR; LIU, 2014a; LIU; PINTO; LIU, 2015)). However, our data suggests that developersare actively performing energy-aware changes. In this RQ we analyze how certain softwaredevelopers are that a modification will impact energy consumption.

By using the method described in Section 2.3.3.2 we found a total of 96 energy-awarecommits that contained hedging instances related to the energy consumption impact. This highnumber encompasses 11.62% of our whole energy-aware set. Examples of such hedgings are:“may cause a degredation in power consumption” [C9] , “seems to improve performance andreduce power consumed in AV record use-case” [C10], “Including some power savings modes. Idoubt they amount to much” [C11], “should aid in further reducing power consumption” [C12].These numbers are similarly reflected by the survey answers where 22.06% of the responsesfor commits that intended to save energy mentioned that they only assumed the change had thedesired impact while 23.53% said that they never actually measured the impact to confirm. Thisdata is an indicative that they are willing to perform a change even when not fully aware of itsoutcome.

One might argue that the hesitation happens only when a GITHUB contributor is perform-ing a non-trivial task with several code changes. However, we found cases where a GITHUBcontributor is performing a single variable change, but he is not sure if the change will positivelyreduce the energy consumption. For instance: “ This patch disables [a feature] and advertisesonly SWSUP mode which seems to improve performance and reduce power consumed in AVrecord usecase”. Table 3.4 summarizes the statistics for the number of total changes and numberof files touched per hedging commit. We can see that at least half of the commits perform lessthan 35 changes and that only 1 file is actually touched.

Considering the stack level, 52 commits containing hedges were related to softwarechanges at the OS level, while 14 were related to Libraries/Utilities and 30 were related to theApplication level. This is equivalent to 13.37%, 8.81% and 10.79% of the OS, Libraries/Utili-ties and Application commits, respectively. When taking into account the developers energy-

Page 46: Por Irineu Martins de Lima Moura - UFPE...Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring

3.4. RQ3 TO WHAT EXTENT ARE SOFTWARE DEVELOPERS CERTAIN OF THEENERGY CONSUMPTION IMPACT OF THEIR CHANGES? 45aware intentions, 79 of the hedging commits were ENERGY-SAVING, 11 were ENERGY-TRADEOFF and 6 were ENERGY-AWARE INTERFACE, that equals to 12.36%, 12.36%and 6.12% of the total commits for each category, respectively.

In our energy-aware set, we also observed that 48 (5.81%) commits were reverting aprevious commit. Revert is a GIT feature that creates a new commit by undoing changes of aprevious commit; if not altered by the developer, the message of a GIT revert commit follows aspecific easily identifiable pattern, e.g., “Revert "pegasusq: more tweaking for battery life" Thisreverts commit 1373891cb2c515d75928a 123211d2c280d0fbdd0.” [C13]. We also consideredcommits as a revert if the survey response for the commit indicated so, even if the commitmessage did not follow the GIT revert pattern. Interestingly, a considerable number of thereverted commits, five of them, undid previous changes that added the power efficient workqueue. According to the documentation, “Workqueues can be performance or power oriented.For performance we may want to keep them running on a single cpu, so that it remains cache hot.For power we can give scheduler the liberty to choose target cpu for running work handler”5.This result at least suggests that the decision of when to use a power-efficient library shouldbe made with care; the trade-off between performance and energy consumption is not alwaysclear (PINTO; CASTOR; LIU, 2014b; LI et al., 2013; HAO et al., 2013).

We also found seven instances of commits in our energy-aware set with comments thateither contradicted the effectiveness of the change being performed or informed that the changewas actually causing issues. For example, after a three lines commit [C28] that updated thevalues of two variables, another developer commented that “These don’t do anything” whenreferring to the energy saving change in question, to which the author replied stating that “(sic) is

strange because with this the duration of battery is better”. These same variables were updatedin at least nine other commits with alternating values in different repositories. This hints thatthere may not always be a consensus among them regarding energy-aware changes.

Another four commits called our attention because developers where introducing changesto fix energy bugs that were actually caused by a previous attempt at reducing energy consumption.Two of these instances were acknowledged after clarifications from the survey answers. In oneof them [C45], the author was trying to stop a screen drawing surge that was caused by a formerattempt at reducing the drawing amount his application was performing. Even after the fix, theauthor mentioned that he did not conduct any form of measuring to confirm that the fix hadthe intended impact. In an even worse scenario [C46], a second survey respondent was solvingan energy bug caused by a previous effort at fixing an energy bug, the change in question wasreverting a previous modification that destroyed several UI elements, but that ultimately led theapplication to spend more time recreating the elements and wasting even more energy. To reallysolve the battery drain issue, the author stated that the whole component had to be rebuilt.

All these findings suggest that developers are not always confident when performingchanges that impact the energy consumption footprint of their software and that even when they

5http://lwn.net/Articles/548281/

Page 47: Por Irineu Martins de Lima Moura - UFPE...Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring

3.5. RQ4 WHAT SOFTWARE QUALITY ATTRIBUTES MAY BE GIVEN PRECEDENCEOVER ENERGY CONSUMPTION? 46are not sure of the impact, they are still willing to take the risk and perform the changes. Itprompts us to inquiry them further on why they hesitate and, considering the survey answers,provide better measurement tools so they can be more assertive when introducing their changes.

3.5 RQ4 What software quality attributes may be given prece-dence over energy consumption?

This research question tries to explore the possible reasons or motivations that leaddevelopers to purposefully worsen a software energy footprint or to disable an energy savingmeasure, here we focus particularly in the ENERGY-TRADEOFF commits. We have observed89 cases where GITHUB contributors are trading software energy consumption for other softwareattributes. Unfortunately, for 49 of these, the authors did not specify what was actually beingtraded off. This happens mainly because the commit message was poorly elaborated and wecould not infer any clear intention from it. Examples of such hard to understand commit messagesare (1) “no power saving in X” [C29], (2) “power saving disabled by default” [C30], and (3)“turns off screen power saving” [C31]. More importantly, however, we observed that in many ofthe aforementioned cases, the GITHUB contributor is disabling/removing the power saving modeprovided by a third-party device.

For the 40 remaining ones, we observed that the most traded software attributes are thefollowing: “Performance”, “Responsiveness”, “Correctness”, “No actual energy saving”, and“Miscellaneous”. Table 3.5 summarizes the number of commits for each attribute. We nowdescribe them.

3.5.1 Performance (10 occurences)

As expected, programmers trade energy consumption for better performance, for instance:“The lowest power level does not correspond to significant power savings as the whole system

doesn’t drop to SVS voltage. Performace is improved without this level for serialized test

cases” [C32].

3.5.2 Responsiveness (10 occurences)

Responsiveness is an important software attribute in general, and for smartphones inparticular. In this regard, two out of the ten occurrences are related to touch events, for instance:“For better Ux responsiveness ondemand sampling rate needs to be 20ms. But, a 20ms sampling

rate increases power consumption. So, boost the sampling rate to 20ms on every touch event for

2.5 ms and later reset to default rate” [C33]. Other two occurrences are related to wifi usage, forinstance: “Wi-Fi should be in active state during the entire DHCP process, and shouldn’t go to

IEEE 802.11 power save mode. If the framework requests scan during the DHCP process, the

Page 48: Por Irineu Martins de Lima Moura - UFPE...Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring

3.5. RQ4 WHAT SOFTWARE QUALITY ATTRIBUTES MAY BE GIVEN PRECEDENCEOVER ENERGY CONSUMPTION? 47Wi-Fi chip has to start scanning on channels different from the current one, and going to power

save mode is a prerequisite for scan. The result directly impacts user experience: DHCP process

takes longer, and even can fail” [C34].

3.5.3 Correctness (8 occurences)

One of the most interesting observations from this group of commits is that ill-chosenenergy saving techniques can impact on the correctness of a software. As stated by differentGITHUB contributors, for instance (1) “the power saving delay has the ability to corrupt serial

transmissions. Changing these to regular delays fixes this” [C35], (2) “USB autosuspend might

be causing some trouble with various smartboards and WLAN accesspoints” [C36] where“autosuspend” is a power saving mode, and (3) “Disable Auto Power Saving when resetting the

modem. This can cause several bugs with serial communication” [C37]. Likewise many ofthe ENERGY-TRADEOFF commits that did not contain a reason, the change performed formost of the correctness problems was the disabling of a power saving mode. In particular, twoGITHUB contributors have acknowledged the same correctness problem: power saving mode

can corrupt serial transmission. We also found an instance of an ENERGY-SAVING commitwhere the developer took extra precaution to avoid falling into issues caused by the power savingmode of a third-party device: “The issue is that power saving is poorly implemented on the

Ublox 6 so we need to be careful not to miss it loosing lock or it’ll freeze up” [C38]

3.5.4 No actual savings (3 occurences)

Some GITHUB contributors did not observe any effective energy saving with a previousemployed solution. In these commits, the GITHUB contributor is removing the supposed energy-efficient code. For instance, “Enable LPA playback for music streams only. There are no

significant power savings for using LPA with other modes like ringtone”[C39], or “It is unlikely

this gives any power savings and only add some ugly code”[C40]. Since we did not find anymention to energy consumption profiling tools in the commit messages, we believe that thisperception of lack of energy saving is based on developers’ own wisdom. However, reasoningabout the energy behavior of an application is not a straight-forward task (PINTO; CASTOR;LIU, 2014a).

3.5.5 Miscellaneous (9 occurences)

We grouped the remaining commits in this category. They varied greatly from improvingthe accuracy of a location service [C41]; to freeing storage space [C42]; and preventing thesystem from going into power saving mode to not disrupt the user experience [C43]; or removinga previous default CPU limit to instead allow the user to decide whether energy saving orperformance should be favored [C44].

Page 49: Por Irineu Martins de Lima Moura - UFPE...Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring

3.6. DEVELOPERS SURVEY 48

Table 3.5: Quality attributes favored over energy-consumption

Attribute # commits %Performance 10 11.24Responsiveness 10 11.24Correctness 8 8.99No actual savings 3 3.37Miscellaneous 9 10.11No reason 49 55.06

Table 3.6: Survey energy saved answers

Energy saved? Answers %Yes 57 83.82No 2 2.94Other 9 13.24

3.6 Developers Survey

In this section we recall some of the survey information that was previously referencedin the research questions and discuss the remaining topics not already covered.

From Table 2.2 we can see that the survey response rate was 10.66% over a total of769 emails delivered. This survey was sent to 583 authors from commits found in 648 differentGITHUB repositories.

Regarding the changes that actually aimed at saving energy (68 responses), when askingabout their effectiveness: 57 (83.82%) responses stated that it did or they assumed it did saveenergy; 2 (2.94%) said it did not, with one stating that the change actually introduced a bug inthe software in question; and for the remaining 9 (13.24%), the respondents were unsure, didnot remember, simply did not answer or we could not comprehend what the respondent wastrying to convey (1 case only). For this same set of energy-saving commits, when inquiring aboutthe knowledge of the energy consumption impact6: 19 (27.94%) did not specify whether therewas any measurement performed, 16 (23.53%) explicitly mentioned that they never measured itand 29 (42.65%) answered that they verified the impact by some type of measurement. Thesenumbers slightly differ from the results of a recent survey conducted with software developers inwhich only 10% stated that they measure energy consumption of their software (PANG et al.,2015). The measurements included (1) informally observing the battery life of the device afterthe change, (2) using hardware apparatus like multimeters or special purpose battery monitorsor (3) using software tools like OS profilers or energy managers. Some authors mentioned thatthey did not actually observe energy consumption itself, but rather the usage of some component(e.g., CPU, video card fan) or feature (e.g., wakelock). However, caution must be taken when

6These numbers do not add up to 100% over the total energy-saving ones because we do not count 3 that did notanswer the question about whether there was any energy saving.

Page 50: Por Irineu Martins de Lima Moura - UFPE...Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring

3.7. FURTHER ANALYSIS 49

using indirect methods because even when using the proper tools the results may be unreliable(SABORIDO et al., 2015). One author also state that he knew the energy consumption improvedbecause a Quality Assurance team had approved his application; previous to his energy-savingchange [C63], this same application had been disapproved due to its energy inefficiency.

3.6.1 Assessment

One of the survey purposes was to evaluate our assessment of the commits. In thisregard, we cross-checked our initial classification for each commit with our classification afterreading the author response. We had a misclassification rate of 13.79% over the total e-mailsanswered (87). All the misclassification instances were related to commits resulting from theinitial phase query and occurred among all the three different types of energy-aware commits, i.e.,we had misclassification instances for changes that we initially considered ENERGY-SAVING,ENERGY-TRADEOFF or ENERGY-AWARE INTERFACE. We can attribute this to ourinitial lack of experience classifying the commits and due to the notion of an energy-awarecommit still being in development. Also, most of the manual work performed during the secondphase was done using an user interface purposefully built for it. The interface placed severaldifferent types of information in a single view to help reasoning about the commit. Nonetheless,this fact warns us that we should be even more careful when deriving intention from commitmessages and to improve our methodology for future works.

3.7 Further Analysis

In this section we discuss several other findings that called our attention during theexploration.

3.7.1 Energy-Aware Interfaces

We identified 98 commits that were performed with the intention to create what we call“energy-aware interfaces” (see Definition 2). An energy-aware interface provides means forclients (e.g., developers or end-users) to save energy in their software just by using a function,abstracting away the low-level implementation details or by allowing to fine tune controlsexposed by such interfaces. These interfaces are of particular importance to end-users because,without them, they would not be able to access such low-level implementation details, e.g.,

because they work on the kernel mode. For example project android_packages_apps_Settings,which is an Android system application. In its energy-aware commit [C22] it adds a feature onthe application’s menu that allows end-users to save energy by disabling mobile data networkswhen the screen is off — an end-user centric approach. On the other hand, project i9105Sammy

adds a new DVFS governor designed for latency-sensitive workloads. According to the commitmessage [C23], this governor “attempts to reduce the latency of clock increases so that the

Page 51: Por Irineu Martins de Lima Moura - UFPE...Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring

3.7. FURTHER ANALYSIS 50

system is more responsive to interactive workloads in loweset steady-state but to reduce power

consumption in middle operation level up will be done in step by step to prohibit system from

going to max operation level”, a programmer-centric approach. Commit [C24] on the otherhand, enables the fine tuning of an RCU parameter that impacts energy-efficiency (among otherthings) depending on how many cores a given system has. However, as in many circumstances,we believe that there must be a balance when adding such interfaces to avoid delegating toomuch responsibility to the users or developers. For users, presenting too many options mayconfuse them and not allow them to understand the implications of using such features. Fordevelopers, new parameters usually means more variability added to their software and, in turn,more obligations to be accounted for.

3.7.2 Context-aware energy saving

We found a total of 78 context-aware commits that follow a check-then-act idiom. Insuch commits, the programmer first verifies a given system condition is met and, if so, acts.For instance, the programmer checks if the GPU is active, prior to collecting a sample. Suchprogramming style is useful to avoid unnecessary work. We have found this programming stylein different contexts, such as: (1) “Disable accelerometer sensor while in-call and screen UI

is off ” [C47], and (2) “charger: suspend when not animating” [C92]. Yet, such check-then-actstyle can be useful to bulk different energy saving techniques, for instance, “turns mobile data

and autosync on and off automatically [...] while the phone is inactive, turns Wifi and Bluetooth

off when disconnected for a period of time, and reduces screen brightness and timeout when

battery levels get low” [C48].

3.7.3 Mobile Environment and Android

Thanks to the rapid proliferation of mobile phones, tablets, and unwired devices ingeneral, energy-efficiency is becoming a key software design consideration where the energyconsumption is closely related to battery lifetime. We found at least 473 commits that aretargeting software for mobile devices. Out of these we see a great Android prevalence, withover half (451) of the energy-aware set being related to an Android application (104), library(91) or kernel fork (256). Considering its partially open source development model and thatis has a mirror of the public repository in GITHUB itself, it is actually not unusual to expectsuch discrepancy. This is yet another sign showing how import energy-consumption is to mobiledevelopers.

3.7.4 High number of soft-duplicates

Our final dataset contained a high number of duplicates (865) and soft-duplicate (200)commits, we believe this to be a threat to researches that are solely based on automatically

Page 52: Por Irineu Martins de Lima Moura - UFPE...Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring

3.8. THREATS TO VALIDITY 51

collected statistics. We highlight the importance of properly filtering out duplicate data thatmight only introduce noise and bias in the final result.

3.7.5 Power efficient workqueue

Although the use of a power efficient workqueue had an expressive number of instancesin our sample, we saw several cases of commits (5) that reverted a previous power efficientworkqueue addition, in particular, among these reverted commits we saw two statements thatcontradicted the efficiency of such data structure for specific scenarios. In one of such case thesurvey respondent mentioned that the gains of using such queues were marginal (”In theory, it

will help reduce power consumption. But in real life usage, it is hardly noticeable”), althoughupon further inquiry the respondent said that the statement was not in general and that it wasapplicable specifically to his Android smartphone. In another instance, the commit [C25] wasreverting the addition of such workqueue because it actually worsened the energy consumptionof the target system. However, this same commit also acknowledged the energy saving potentialof such workqueues for systems with many cores.

3.7.6 Energy-Aware Source Code Review

As previously mentioned, on GITHUB, when a commit is pushed to a repository, otherGITHUB contributors can provide comments to the commit, so that the original author canimprove the existing commit based on the comments provided in order to match with the teamexpectations. In fact, we found 20 energy-aware commits that contained discussions. Thesediscussions are mostly related to the behavior of the application on a particular scenario, forinstance, “and if someone disabled the background-process, but enabled the "kernel-tweaks"

?” [C27], nonetheless we considered seven of these directly related to the energy-aware change.For example, we found one thorough discussion about the appropriateness of an energy savingchange [C8] for a specific system. This low number of discussions found does not suggest,however, that developers do not have interest in discussing energy consumption issues. Accordingto a recent study, only few developers contribute to a broader range of design discussions in aproject (BRUNET et al., 2014).

3.8 Threats to Validity

3.8.1 Internal

First, we collected the commits using a GITHUB third-party mirror called GITHUBARCHIVE.As it at came to our knowledge in late stages of this research, this mirror does not contain allcommits available on GITHUB. Up to late 2014, it only contained the commits that were at

Page 53: Por Irineu Martins de Lima Moura - UFPE...Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring

3.8. THREATS TO VALIDITY 52

the tip of branch push events7. This is, however, a reasonable approach that we found, sinceGITHUB itself does not provide an interface for querying commit messages among differentsoftware repositories. Second, our approach does not cover the whole spectrum of energy-relatedcommit messages since developers have many different ways to describe a change. To make thematters worse, commit messages are often vague, meaningless, or have typo errors. We mitigatethis problem by searching with wildcards. Thus, we can query terms regardless their position(in the beginning, middle or end) in the commit message. Wildcards also allow us to querypart of the term (e.g., “consum*”, instead of “consumption”), which can cover abbreviations,typos or similar words. Third, commits categorization is human-prone. For instance, a commitmight be seen as “ENERGY-SAVING” for one, but “ENERGY-AWARE INTERFACE” foranother one. We mitigate this risk by at least doubling-check each one of the analyzed commits.When the authors did not agree with each other, a third author was invited to the discussionand provided additional comments. We also surveyed the authors to reduce classification bias.This same subjectivity note also applies to Thematic Analysis used to answer RQ1 , a differentresearcher could have come to slightly different themes and/or themes descriptions and names.Fourth, we only analyzed commit messages written in English. However, English is the de facto

language used to communicate in software development. Finally, since we are not the commitauthors, some findings might appear as an over/under-generalization.

3.8.2 External

First, our results only apply to software developers who performed energy-aware commitson GITHUB. It does not cover the entire population of software developers. Second, our resultsare limited by our selection of commit messages. Such commits were performed in wide spectrumof the stack level, ranging from operating systems kernels to mobile or browser applications.These applications were developed by different teams, using different programming languages,from a large and varied community. Third, there are other possible energy-related source codemanipulations beyond the scope of this paper. With our methodology, we expect that similaranalysis can be conducted by others when they become relevant. Fourth, for the themes describedin Section 3.2, this work does not address the problem of understanding whether these sourcecode modifications actually impact the energy consumption in the described ways. Althoughwe provide some discussions based on the source code modifications, it is known that energyconsumption is heavily application-dependent (PINTO; CASTOR; LIU, 2014b). A definitiveanswer would require a in-depth runtime investigation of each target system. Lastly, as presentedin Section 2.3.2.1, many of the commits in our sample were not available on GITHUB anymoreat the time of querying, and during the course of the research some commits also became

7When pushing a branch to GITHUB the GITHUBARCHIVE database did not store information about commitsthat were in between the latest commit pushed and the commit at the tip of the branch being pushed, e.g., if C1 wasthe latest commit and commits C2 <- C3 were being pushed as part of branch B, then there would be an event forC3 but not C2 in the GITHUBARCHIVE database. As of 2015 they have fixed this issue.

Page 54: Por Irineu Martins de Lima Moura - UFPE...Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring

3.8. THREATS TO VALIDITY 53

unavailable. This is a threat to the replicability of such studies since researchers would not beable to replicate it in possible subsequent works considering the same time range. To alleviatethis concern, we make publicly available all commit data that was collected through the manualanalyses in the form a Google Spreadsheet8 as well as commit (and commit related) metadatagathered using the GITHUB API in the form of a MONGODB dump9. This dump containsinformation such as:

� Commit metadata that is usually available through the GITHUB web interface suchas commit message; author and committer email address; dates of authorship andcommit; and the patch showing the changes introduced by the commit;

� Repository metadata for the repositories that received commits in our dataset;

� User metadata for author and committers that had public accounts on GITHUB

Even if the data used in this study becomes unavailable on GITHUB, one can use our curated datatogether with an UI (see Section 2.5) to visualize the commits and read through the data. Moredetails about the spreadsheet and the dump can be found on-line10. We expect to encourageothers to replicate our study.

8https://docs.google.com/spreadsheets/d/1QWa4nGL8U4EK1B5oA79eEVl7fFpD36CAoVwct0yMj3E/edit?usp=sharing

9http://docs.mongodb.org/manual/core/backups/10http://imlm.github.io/energy-aware-mining/

Page 55: Por Irineu Martins de Lima Moura - UFPE...Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring

545454

4Conclusion

The work presented in this thesis has explored a set of energy-aware commits with theintent of learning how open-source developers are actually modifying software when dealingwith energy consumption. From a sample of almost 4.000 commits we curated an energy-awareset which was then used to answer our research questions. We also surveyed the commit authorsto broaden our understanding of these modifications. In this section we summarize our results.

In RQ1 we showed the seven most common solutions employed by developers in ourenergy-aware set when trying to improve energy consumption. These solutions covered themeslike Energy bug fix, Frequency and voltage scaling, Disabling components, Low power idling,Managing periodic work and Timing out. The most common themes were Energy bug fix andFrequency and voltage scaling, both together totaled 142 commits which is equivalent to 33.10%of the analyzed commits.

For RQ2 we showed that most of the changes (47.09%) in our energy-aware set werestill targeting the lower levels of the software stack while application level changes covered only33.66% of the commits and changes to Libraries/Utilities encompassed just 19.25% of them.However our data suggests a steady growth in the number of application level changes over theyears.

In RQ3 we presented several indicators showing that developers might not always becertain that a given change will have its intended effect and yet they are still willing to perform it.Some of these indicators were the relatively high number (11.62%) of energy-aware commitswith hedging cues and the fact that 23.53% of the survey responses for the energy-saving commitsindicated that they have never measured the actual impact. This eagerness should prompt theresearch community to work even harder on finding solutions to help them in improving theirsoftware energy efficiency.

RQ4 presented the different software quality attributes that might be favored over energyefficiency. We showed that developers are willing to trade energy consumption for attributes likePerformance, Responsiveness and Correctness and we highlight this last one which indicatesthat ill-chosen energy saving techniques can have a detrimental impact on the target system.

We also observed other interesting findings. For example, the discovery of energy-aware

Page 56: Por Irineu Martins de Lima Moura - UFPE...Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring

4.1. RELATED WORK 55

interfaces which enable other users and developers to control energy consumption of their system.And the confirmation of the mobile community interest in improving energy efficiency, over halfof our analysis set was related to software targeting the mobile environment.

4.1 Related Work

Most of the existing software empirical research has focused on the trade-off of compar-ing individual characteristics of an application and energy consumption. These characteristicsvary from data structures (DAYLIGHT et al., 2002; HUNT; SANDHU; CEZE, 2011; MANO-TAS; POLLOCK; CLAUSE, 2014), VM services (CAO et al., 2012), cloud offloading (KWON;TILEVICH, 2013), code obfuscation (SAHIN et al., 2014), and design patterns (SAHIN et al.,2012; LI; HALFOND, 2014). Such research serves as a guideline for future energy-awareapplication programmers.

The mobile arena is also an important topic of research. Hindle (HINDLE, 2012)investigated the relationship between software changes (several versions of the Mozilla Firefoxapp) and power consumption. The author observed that intentional performance optimizationintroduced a steady reduction in power consumption. Pathak et al. (PATHAK; HU; ZHANG,2011) categorized energy bugs through analyzing the posts from four online forums. Theyproduced a comprehensive taxonomy ranging from battery problems, SIM card problems, OSconfiguration problems, to no-sleep bugs. Pathak et al. (PATHAK; HU; ZHANG, 2012) presentedan investigation aiming to understand the root causes for energy consumption problems in mobileapplications. Linares-Vasquez et al. (LINARES-VÁSQUEZ et al., 2014) investigated AndroidAPI usage patterns that can potentially consume high energy consumption. The authors observedthat while some anomalous energy consumption are unavoidable, some can be avoided by usingcertain categories of Android APIs and patterns. Similarly, Li et al. (LI et al., 2014) presentedthe a large scale study on the energy-efficiency of mobile applications. Among their findings, wedescribe two of interest: (1) a few set of APIs used in applications dominate non-idle energyconsumption and (2) an HTTP request is the most energy consuming operation of the network.

Regarding the topic of understanding what are the solutions proposed by software devel-opers in order to improve software energy consumption, (PINTO; CASTOR; LIU, 2014a) minedSTACKOVERFLOW, a programmer-centric website, considering a developer-oriented view ofenergy-aware software development. This work provides useful insights such as the most commonenergy consumption related problems, and the solutions to them. (PANG et al., 2015) followedup on Pinto’s study by surveying developers to understand how knowledgeable they were whenregarding software energy consumption. Their results showed that developers had limited knowl-edge about energy efficiency, were not fully aware of best practices to reduce energy consumptionand were not always sure about how software consumes energy. In (MALIK; ZHAO; GODFREY,2015), the authors did a partial replication of the same STACKOVERFLOW study, but focusing onAndroid and iOS questions and expanding the keywords used for searching. They found that

Page 57: Por Irineu Martins de Lima Moura - UFPE...Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring

4.2. FUTURE WORK 56

developers from both platforms discuss energy related questions closely to the same degree andthey also showed the most common energy related issues discussed by these developers, whichenergy related topics are also common in non-energy related questions and the most commondiscussed types of the Java language programming language that are strongly associated withenergy consumption issues.

However, these works focused on what developers believe. In contrast, the researchdescribed in this document provides a set of solutions that developers actually employ in thehope of saving software energy consumption as well as other energy-consumption relatedmodifications.

4.2 Future Work

Due to its exploratory nature, this research can spawn a multitude of possibilities forfuture work. In this section we list some of them.

Assessing the validity of the energy saving techniques was outside the scope of thisresearch, nonetheless, this seems a natural path to follow. One could use as a starting pointthe themes described in Section 3.2 and empirically assess their effectiveness across differentdomains much like the work of (LI; HALFOND, 2014). Another approach could be focusingon specific domains or environments and assess the validity of the techniques that we observedfor these domains. After assessing their validity, one could elaborate on solutions definingtheir motivation, scope, implications and so forth, in a similar fashion to a refactoring catalog(FOWLER, 1999).

Another venue to follow is investigating the energy bugs that we found in our energy-aware set. We found a total of 72 fixes for such bugs that varied from sleep prevention or constantwake ups bugs, to resource leaks, excessive components usage and endless computations. Wecould invest time examining these commits in-depth and trying to understand how they wereintroduced in the code base, how they were uncovered, how was the process that lead to theirresolution and what steps were taken to prevent such bugs in the future.

A third venue is investigating the circumstances in which developers hedge and itspossible implications. As was demonstrated in Section 3.4, there was a considerable number(96) of hedging instances among our dataset and this was also reflected by email survey answers.Investigating the rationale behind such hesitation instances can be a good way of understandingthe developers real needs when dealing with energy consumption. We could also investigate ifthere is any relationship between hedging in commit messages (or other software artifacts) andnegative impacts caused by such commits. A valid alternative is looking for correlations betweenhedges and energy bugs or failed attempts at improving energy consumption. The assumptionis that not being fully aware of the impacts of a change before performing it could introduceundesired side effects or even have the contrary effect.

A fourth and last path is increasing the scope of our search. As mentioned in the Sec-

Page 58: Por Irineu Martins de Lima Moura - UFPE...Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring

4.3. OTHER CONTRIBUTIONS 57

tion 3.8, we did not sample the whole universe of commits pushed to GITHUB due to limitationsof the service we chose for querying, thus there are potentially even more different types ofenergy-aware commits within the time frame we specified. A different service (GOUSIOS, 2013)could be used to go after these missing commits. Additionally, GITHUB is a growing platformand surely more energy-aware commits have been pushed since the end date of our query, soincreasing the time range could be another option to uncover new techniques and to make newobservations.

4.3 Other contributions

This work has already produced a research paper that was accepted to the 12th WorkingConference on Mining Software Repositories (MSR’15)1 and presented on May 16th of 2015.The paper results only covered the initial sample (battery/energy) and did not consider thesurvey contents. This paper also received an invitation to appear as a write up in a column forIEEE Software Magazine. We believe this to be a good sign and it shows that this type of workcan be a good research venue to follow.

1http://2015.msrconf.org/program.php

Page 59: Por Irineu Martins de Lima Moura - UFPE...Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring

585858

References

AGARWAL, S.; YU, H. Detecting hedge cues and their scope in biomedical text withconditional random fields. Journal of biomedical informatics, [S.l.], v.43, n.6, p.953–961,2010.

BRAUN, V.; CLARKE, V. Using thematic analysis in psychology. Qualitative research inpsychology, [S.l.], v.3, n.2, p.77–101, 2006.

BRUNET, J. a. et al. Do Developers Discuss Design? In: WORKING CONFERENCE ONMINING SOFTWARE REPOSITORIES, 11. Proceedings. . . [S.l.: s.n.], 2014. p.340–343.(MSR 2014).

CAO, T. et al. The Yin and Yang of Power and Performance for Asymmetric Hardware andManaged Software. In: ANNUAL INTERNATIONAL SYMPOSIUM ON COMPUTERARCHITECTURE, 39. Proceedings. . . [S.l.: s.n.], 2012. p.225–236. (ISCA ’12).

Cat Phones. New Research Reveals Mobile Users Want Phones to Have a Longer ThanAverage Battery Life. Disponível em: <http://bit.ly/1Eccqr3>. Acessado em: 14fev. 2015.

CHACON, S. Pro git. [S.l.]: Apress, 2009.

DAVID, H. et al. RAPL: memory power estimation and capping. In: ACM/IEEEINTERNATIONAL SYMPOSIUM ON LOW POWER ELECTRONICS AND DESIGN, 16.Proceedings. . . [S.l.: s.n.], 2010. p.189–194. (ISLPED ’10).

DAYLIGHT, E. G. et al. Incorporating Energy Efficient Data Structures into Modular SoftwareImplementations for Internet-based Embedded Systems. In: INTERNATIONAL WORKSHOPON SOFTWARE AND PERFORMANCE, 3. Proceedings. . . [S.l.: s.n.], 2002. p.134–141.(WOSP ’02).

ELLIS, C. S. The case for higher-level power management. In: HOT TOPICS IN OPERATINGSYSTEMS, 1999. PROCEEDINGS OF THE SEVENTH WORKSHOP ON. Proceedings. . .[S.l.: s.n.], 1999. p.162–167.

FARKAS, K. I. et al. Quantifying the Energy Consumption of a Pocket Computer and a JavaVirtual Machine. In: ACM SIGMETRICS INTERNATIONAL CONFERENCE ONMEASUREMENT AND MODELING OF COMPUTER SYSTEMS, 2000. Proceedings. . .[S.l.: s.n.], 2000. p.252–263. (SIGMETRICS ’00).

FOWLER, M. Refactoring: improving the design of existing code. [S.l.]: Pearson EducationIndia, 1999.

GOOGLE. Eficciency: how can other do it – data centers. Disponível em:<http://www.google.com/about/datacenters/efficiency/external/>.Acessado em: 21 jan. 2015.

GOUSIOS, G. The GHTorrent dataset and tool suite. In: WORKING CONFERENCE ONMINING SOFTWARE REPOSITORIES, 10., Piscataway, NJ, USA. Proceedings. . . IEEEPress, 2013. p.233–236. (MSR ’13).

Page 60: Por Irineu Martins de Lima Moura - UFPE...Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring

REFERENCES 59

GRIGORIK, I. GitHub Archive. Disponível em:<https://www.githubarchive.org>.

HAO, S. et al. Estimating mobile application energy consumption using program analysis. In:INTERNATIONAL CONFERENCE ON SOFTWARE ENGINEERING, ICSE ’13, SANFRANCISCO, CA, USA, MAY 18-26, 2013, 35. Proceedings. . . [S.l.: s.n.], 2013. p.92–101.

HINDLE, A. Green mining: a methodology of relating software change to power consumption.In: MINING SOFTWARE REPOSITORIES (MSR), 2012 9TH IEEE WORKINGCONFERENCE ON. Proceedings. . . [S.l.: s.n.], 2012. p.78–87.

HOROWITZ, M.; INDERMAUR, T.; GONZALEZ, R. Low-power digital design. In: LOWPOWER ELECTRONICS, 1994. IEEE SYMPOSIUM. Proceedings. . . [S.l.: s.n.], 1994.

HUNT, N.; SANDHU, P. S.; CEZE, L. Characterizing the Performance and Energy Efficiency ofLock-Free Data Structures. In: WORKSHOP ON INTERACTION BETWEEN COMPILERSAND COMPUTER ARCHITECTURES, 2011. Proceedings. . . [S.l.: s.n.], 2011. p.63–70.(INTERACT ’11).

HYLAND, K. Hedging in scientific research articles. [S.l.]: John Benjamins Publishing, 1998.v.54.

JIN, G. et al. Understanding and detecting real-world performance bugs. In: ACM SIGPLANCONFERENCE ON PROGRAMMING LANGUAGE DESIGN AND IMPLEMENTATION.Proceedings. . . [S.l.: s.n.], 2012. p.77–88.

KALLIAMVAKOU, E. et al. The promises and perils of mining GitHub. In: WORKINGCONFERENCE ON MINING SOFTWARE REPOSITORIES, 11. Proceedings. . . [S.l.: s.n.],2014. p.92–101.

KAMBADUR, M.; KIM, M. A. An experimental survey of energy management across the stack.In: ACM INTERNATIONAL CONFERENCE ON OBJECT ORIENTED PROGRAMMINGSYSTEMS LANGUAGES & APPLICATIONS, 2014. Proceedings. . . [S.l.: s.n.], 2014.p.329–344.

KWON, Y.; TILEVICH, E. Reducing the Energy Consumption of Mobile Applications Behindthe Scenes. In: IEEE INTERNATIONAL CONFERENCE ON SOFTWARE MAINTENANCE,EINDHOVEN, THE NETHERLANDS, SEPTEMBER 22-28, 2013, 2013. Proceedings. . .[S.l.: s.n.], 2013. p.170–179.

LI, D. et al. Calculating Source Line Level Energy Information for Android Applications. In:INTERNATIONAL SYMPOSIUM ON SOFTWARE TESTING AND ANALYSIS, 2013.Proceedings. . . [S.l.: s.n.], 2013. p.78–89. (ISSTA 2013).

LI, D. et al. An empirical study of the energy consumption of android applications. In:SOFTWARE MAINTENANCE AND EVOLUTION (ICSME), 2014 IEEE INTERNATIONALCONFERENCE ON. Proceedings. . . [S.l.: s.n.], 2014. p.121–130.

LI, D.; HALFOND, W. G. An investigation into energy-saving programming practices forandroid smartphone app development. In: INTERNATIONAL WORKSHOP ON GREEN ANDSUSTAINABLE SOFTWARE, 3. Proceedings. . . [S.l.: s.n.], 2014. p.46–53.

Page 61: Por Irineu Martins de Lima Moura - UFPE...Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring

REFERENCES 60

LINARES-VÁSQUEZ, M. et al. Mining energy-greedy API usage patterns in Android apps: anempirical study. In: WORKING CONFERENCE ON MINING SOFTWARE REPOSITORIES,11. Proceedings. . . [S.l.: s.n.], 2014. p.2–11.

LIU, K.; PINTO, G.; LIU, Y. D. Data-oriented characterization of application-level energyoptimization. In: Fundamental Approaches to Software Engineering. [S.l.]: Springer, 2015.p.316–331.

MALIK, H.; ZHAO, P.; GODFREY, M. Going Green: an exploratory analysis of energy-relatedquestions. , [S.l.], 2015.

MANOTAS, I.; POLLOCK, L.; CLAUSE, J. SEEDS: a software engineer’s energy-optimizationdecision support framework. In: INTERNATIONAL CONFERENCE ON SOFTWAREENGINEERING, 36. Proceedings. . . [S.l.: s.n.], 2014. p.503–514. (ICSE 2014).

MOURA, I. et al. Mining Energy-Aware Commits. , [S.l.], 2015.

PANG, C. et al. What do programmers know about software energy consumption? Software,IEEE, [S.l.], v.PP, n.99, p.1–1, 2015.

PATHAK, A.; HU, Y. C.; ZHANG, M. Bootstrapping Energy Debugging on Smartphones: a firstlook at energy bugs in mobile devices. In: ACM WORKSHOP ON HOT TOPICS INNETWORKS, 10. Proceedings. . . [S.l.: s.n.], 2011. p.5:1–5:6. (HotNets-X).

PATHAK, A.; HU, Y. C.; ZHANG, M. Where is the Energy Spent Inside My App?: fine grainedenergy accounting on smartphones with eprof. In: ACM EUROPEAN CONFERENCE ONCOMPUTER SYSTEMS, 7. Proceedings. . . [S.l.: s.n.], 2012. p.29–42. (EuroSys ’12).

PEREZ, S. iTunes App Store Now Has 1.2 Million Apps, Has Seen 75 Billion DownloadsTo Date. Disponível em: <http://techcrunch.com/2014/06/02/itunes-app-store-now-has-1-2-million-apps-has-seen-75-billion-downloads-to-date/>.Acessado em: 3 mar. 2015.

PEREZ, S. Majority Of Digital Media Consumption Now Takes Place In Mobile Apps.Disponível em <http://techcrunch.com/2014/08/21/majority-of-digital-media-consumption-now-takes-place-in-mobile-apps/>.Acessado em: 7 ago. 2015.

PERING, T.; BURD, T. D.; BRODERSEN, R. W. The simulation and evaluation of dynamicvoltage scaling algorithms. In: INTERNATIONAL SYMPOSIUM ON LOW POWERELECTRONICS AND DESIGN, 1998, MONTEREY, CALIFORNIA, USA, AUGUST 10-12,1998, 1998. Proceedings. . . [S.l.: s.n.], 1998. p.76–81.

PINTO, G.; CASTOR, F. Characterizing the Energy Efficiency of Java’s Thread-SafeCollections in a Multicore Environment. In: SPLASH’2014 WORKSHOP ON SOFTWAREENGINEERING FOR PARALLEL SYSTEMS (SEPS). Proceedings. . . [S.l.: s.n.], 2014.(SEPS ’14).

PINTO, G.; CASTOR, F.; LIU, Y. D. Mining questions about software energy consumption. In:WORKING CONFERENCE ON MINING SOFTWARE REPOSITORIES, 11. Proceedings. . .[S.l.: s.n.], 2014. p.22–31.

Page 62: Por Irineu Martins de Lima Moura - UFPE...Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring

REFERENCES 61

PINTO, G.; CASTOR, F.; LIU, Y. D. Understanding Energy Behaviors of Thread ManagementConstructs. In: ACM INTERNATIONAL CONFERENCE ON OBJECT ORIENTEDPROGRAMMING SYSTEMS LANGUAGES AND APPLICATIONS, 2014. Proceedings. . .[S.l.: s.n.], 2014. p.345–360. (OOPSLA ’14).

RIBIC, H.; LIU, Y. D. Energy-efficient work-stealing language runtimes. In:ARCHITECTURAL SUPPORT FOR PROGRAMMING LANGUAGES AND OPERATINGSYSTEMS, ASPLOS ’14, SALT LAKE CITY, UT, USA, MARCH 1-5, 2014. Proceedings. . .[S.l.: s.n.], 2014. p.513–528.

SABORIDO, R. et al. On the impact of sampling uency on software energy measurements.[S.l.]: PeerJ PrePrints, 2015.

SAHIN, C. et al. Initial explorations on design pattern energy usage. In: FIRSTINTERNATIONAL WORKSHOP ON GREEN AND SUSTAINABLE SOFTWARE, GREENS2012, ZURICH, SWITZERLAND, JUNE 3, 2012. Proceedings. . . [S.l.: s.n.], 2012. p.55–61.

SAHIN, C. et al. How Does Code Obfuscation Impact Energy Usage? In: IEEEINTERNATIONAL CONFERENCE ON SOFTWARE MAINTENANCE AND EVOLUTION,VICTORIA, BC, CANADA, SEPTEMBER 29 - OCTOBER 3, 2014, 30. Proceedings. . .[S.l.: s.n.], 2014. p.131–140.

SAHIN, C.; POLLOCK, L. L.; CLAUSE, J. How do code refactorings affect energy usage? In:ACM-IEEE INTERNATIONAL SYMPOSIUM ON EMPIRICAL SOFTWAREENGINEERING AND MEASUREMENT, ESEM ’14, TORINO, ITALY, SEPTEMBER 18-19,2014, 2014. Proceedings. . . [S.l.: s.n.], 2014. p.36.

STALLINGS, W. Operating Systems - Internals and Design Principles (7th ed.). [S.l.]:Pitman, 2011.

SZARVAS, G. Hedge classification in biomedical texts with a weakly supervised selection ofkeywords. In: MEETING OF THE ASSOCIATION FOR COMPUTATIONAL LINGUISTICS,46. Proceedings. . . [S.l.: s.n.], 2008.

THEGUARDIAN. Facebook ’unfriends’ coal and ’likes’ clean power. Disponível em:<http://www.theguardian.com/environment/2011/dec/15/facebook-coal-clean-power-energy-greenpeace>. Acessado em: 21 jan. 2015.

VINCZE, V. et al. The BioScope corpus: biomedical texts annotated for uncertainty, negationand their scopes. BMC bioinformatics, [S.l.], v.9, n.Suppl 11, p.S9, 2008.

WAN, M. et al. Detecting Display Energy Hotspots in Android Apps. In: SOFTWARETESTING, VERIFICATION AND VALIDATION (ICST), 2015 IEEE 8TH INTERNATIONALCONFERENCE ON. Proceedings. . . [S.l.: s.n.], 2015. p.1–10.

WARREN, C. Google Play Hits 1 Million Apps. Disponível em:<http://mashable.com/2013/07/24/google-play-1-million/>. Acessadoem 3 ago. 2015.

WILKE, C. et al. Energy consumption and efficiency in mobile applications: a user feedbackstudy. In: GREEN COMPUTING AND COMMUNICATIONS (GREENCOM), 2013 IEEEAND INTERNET OF THINGS (ITHINGS/CPSCOM), IEEE INTERNATIONAL

Page 63: Por Irineu Martins de Lima Moura - UFPE...Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring

REFERENCES 62

CONFERENCE ON AND IEEE CYBER, PHYSICAL AND SOCIAL COMPUTING.Proceedings. . . [S.l.: s.n.], 2013. p.134–141.

ZHANG, C.; HINDLE, A.; GERMAN, D. M. The impact of user choice on energy consumption.Software, IEEE, [S.l.], v.31, n.3, p.69–75, 2014.

ZHANG, Y. et al. Refactoring Android Java Code for On-demand Computation Offloading. In:ACM INTERNATIONAL CONFERENCE ON OBJECT ORIENTED PROGRAMMINGSYSTEMS LANGUAGES AND APPLICATIONS. Proceedings. . . [S.l.: s.n.], 2012.p.233–248. (OOPSLA ’12).

ZHUANG, Z.; KIM, K.-H.; SINGH, J. P. Improving Energy Efficiency of Location Sensing onSmartphones. In: INTERNATIONAL CONFERENCE ON MOBILE SYSTEMS,APPLICATIONS, AND SERVICES, 8. Proceedings. . . [S.l.: s.n.], 2010. p.315–330. (MobiSys’10).

Page 64: Por Irineu Martins de Lima Moura - UFPE...Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring

Appendix

Page 65: Por Irineu Martins de Lima Moura - UFPE...Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring

646464

AQueries

A.1 First phase sampling query

BigQuery query for the first phase dataset. This query only includes commits related tothe energy and power keywords.

SELECT

(repository_url + ’/commit/’ + payload_commit_id) as commit_link,

repository_url, repository_owner, repository_name,

payload_commit_id, payload_commit_email,

payload_commit_msg, payload_commit_name,

payload_commit_flag, created_at

FROM [githubarchive:github.timeline]

WHERE payload_commit_msg is not null

AND PARSE_UTC_USEC(created_at) <= PARSE_UTC_USEC(’2014-05-15 23:59:59

’)

AND (

REGEXP_MATCH(payload_commit_msg, r’(?i).*power consum.*’ )

OR REGEXP_MATCH(payload_commit_msg, r’(?i).*power efficien.*’ )

OR REGEXP_MATCH(payload_commit_msg, r’(?i).*power sav.*’ )

OR REGEXP_MATCH(payload_commit_msg, r’(?i).*save power.*’ )

OR REGEXP_MATCH(payload_commit_msg, r’(?i).*energy consum.*’ )

OR REGEXP_MATCH(payload_commit_msg, r’(?i).*energy efficien.*’ )

OR REGEXP_MATCH(payload_commit_msg, r’(?i).*energy sav.*’ )

OR REGEXP_MATCH(payload_commit_msg, r’(?i).*save energy.*’ )

)

AND type = ’PushEvent’

GROUP BY commit_link, payload_commit_msg, repository_url,

payload_commit_id, created_at, repository_owner,

repository_name, payload_commit_email, payload_commit_name,

payload_commit_flag

Page 66: Por Irineu Martins de Lima Moura - UFPE...Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring

A.2. SECOND PHASE SAMPLING QUERY 65

ORDER BY created_at asc;

A.2 Second phase sampling query

BigQuery query for the second phase dataset. This query selects only the delta betweenthe battery keyword results and the power/energy keyword results.

SELECT left_commits.commit_link as commit_link,

left_commits.type as type,

left_commits.repository_url as repository_url,

left_commits.repository_owner as repository_owner,

left_commits.repository_name as repository_name,

left_commits.payload_commit_id as payload_commit_id,

left_commits.payload_commit_msg as payload_commit_msg,

left_commits.payload_commit_email as payload_commit_email,

left_commits.payload_commit_name as payload_commit_name,

left_commits.payload_member_id as payload_member_id,

left_commits.payload_ref as payload_ref,

left_commits.created_at as created_at,

FROM (

SELECT (repository_url + ’/commit/’ + payload_commit_id) as

commit_link,

type, repository_url, repository_owner,

repository_name, payload_commit_id, payload_commit_msg,

payload_commit_name, payload_commit_email,

payload_member_id, payload_ref, created_at

FROM [githubarchive:github.timeline]

WHERE payload_commit_msg is not null

AND PARSE_UTC_USEC(created_at) <= PARSE_UTC_USEC(’2014-05-15

23:59:59’)

AND (

REGEXP_MATCH(payload_commit_msg, r’(?i).*battery\s+us.*’)

OR REGEXP_MATCH(payload_commit_msg, r’(?i).*us\S+\s+battery.*’)

OR REGEXP_MATCH(payload_commit_msg, r’(?i).*battery\s+red.*’)

OR REGEXP_MATCH(payload_commit_msg, r’(?i).*battery\s+consum.*’

)

OR REGEXP_MATCH(payload_commit_msg, r’(?i).*consum\S+\s+battery

.*’)

OR REGEXP_MATCH(payload_commit_msg, r’(?i).*battery\s+efficien

.*’)

OR REGEXP_MATCH(payload_commit_msg, r’(?i).*battery\s+sav.*’)

Page 67: Por Irineu Martins de Lima Moura - UFPE...Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring

A.2. SECOND PHASE SAMPLING QUERY 66

OR REGEXP_MATCH(payload_commit_msg, r’(?i).*sav\S+\s+battery.*’

)

OR REGEXP_MATCH(payload_commit_msg, r’(?i).*improv\S+\s+battery

.*’)

OR REGEXP_MATCH(payload_commit_msg, r’(?i).*battery\s+improve.*

’)

OR REGEXP_MATCH(payload_commit_msg, r’(?i).*battery\s+life.*’)

)

GROUP BY commit_link, type, payload_commit_msg, repository_url,

payload_commit_id, created_at, repository_owner,

repository_name, payload_commit_name, payload_commit_email,

payload_member_id, payload_ref

ORDER BY created_at desc) AS left_commits

LEFT OUTER JOIN EACH

(

SELECT type, repository_url, repository_owner, repository_name,

payload_commit_id, payload_commit_msg, payload_member_id,

payload_ref, created_at

FROM [githubarchive:github.timeline]

WHERE payload_commit_msg is not null

AND PARSE_UTC_USEC(created_at) <=

PARSE_UTC_USEC (’2014-05-15 23:59:59’)

AND (

REGEXP_MATCH(payload_commit_msg, r’(?i).*power consum.*’)

OR REGEXP_MATCH(payload_commit_msg,

r’(?i).*power efficien.*’)

OR REGEXP_MATCH(payload_commit_msg, r’(?i).*power sav.*’)

OR REGEXP_MATCH(payload_commit_msg, r’(?i).*save power.*’)

OR REGEXP_MATCH(payload_commit_msg,

r’(?i).*energy consum.*’)

OR REGEXP_MATCH(payload_commit_msg,

r’(?i).*energy efficien.*’)

OR REGEXP_MATCH(payload_commit_msg, r’(?i).*energy sav.*’)

OR REGEXP_MATCH(payload_commit_msg,

r’(?i).*save energy.*’)

)

GROUP BY type, payload_commit_msg, repository_url,

payload_commit_id, created_at, repository_owner,

repository_name, payload_member_id, payload_ref

ORDER BY created_at desc

) AS right_commits

Page 68: Por Irineu Martins de Lima Moura - UFPE...Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring

A.2. SECOND PHASE SAMPLING QUERY 67

ON left_commits.created_at = right_commits.created_at

AND left_commits.payload_commit_id =

right_commits.payload_commit_id

WHERE right_commits.created_at IS NULL;

Page 69: Por Irineu Martins de Lima Moura - UFPE...Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring

686868

BScripts

B.1 Availability checking script

function update404s(initIndex, endIndex, sheetName, all_changed) {

if(!all_changed) all_changed = [];

var batcher = new Batcher();

var dataSheet = new SmartSheet(SpreadsheetApp.getActiveSpreadsheet

().getSheetByName(sheetName));

var initialIndex = 1;

if(initIndex !== undefined && initIndex !== null && initIndex > 1)

{

initialIndex = initIndex - 1;

}

var total = endIndex ? endIndex - initIndex : null;

var events = dataSheet.getObjects(true, false, initialIndex, total);

var changedIndexes = [];

for(var i = 0; i < events.length; i++) {

var e = events[i];

try {

var location = e.commit_link;

var redirects = 0;

var resp;

while(location && redirects++ < 3) {

resp = UrlFetchApp.fetch(location, {followRedirects: false});

location = resp.getHeaders().Location;

if(location) {

Page 70: Por Irineu Martins de Lima Moura - UFPE...Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring

B.2. DUPLICATE DETECTION SCRIPT 69

e.redirect_link = location

}

}

if(location) {

changedIndexes.push(i + initialIndex + 1);

e.latest_404_status = "MAX_REDIRECTS_EXCEEDED";

} else if(e.latest_404_status === ’NOT-FOUND-SCRIPT-NOAPI’) {

changedIndexes.push(i + initialIndex + 1);

e.latest_404_status = "FOUND-AGAIN-WAS-NOT-FOUND";

} else if(resp.getContentText().indexOf(’This repository has

been disabled’) > -1) {

e.latest_404_status = "REPOSITORY-DISABLED";

} else if(resp.getContentText().indexOf(’This repository is

empty’) > -1) {

e.latest_404_status = "REPOSITORY-EMPTY";

}

} catch(exception) {

changedIndexes.push(i + initialIndex + 1);

e.latest_404_status = "NOT-FOUND-SCRIPT-NOAPI";

}

if(batcher.timeRunningOut()) {

var args = [initIndex + i + 1, endIndex, sheetName, all_changed.

concat(changedIndexes)];

batcher.batch(’update404s’, args);

return changedIndexes;

}

Utilities.sleep(Math.random() * 500);

}

all_changed = all_changed.concat(changedIndexes);

Logger.log(all_changed.length);

Logger.log(all_changed);

return all_changed;

}

B.2 Duplicate detection script

function findDuplicates(commits, commitsMetadata) {

var duplicates = 0;

Page 71: Por Irineu Martins de Lima Moura - UFPE...Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring

B.2. DUPLICATE DETECTION SCRIPT 70

var dupsBySha = 0;

var dupsByMsg = 0;

commits = _.filter(commits, function(c){ return c.latest_404_status

!== ’NOT-FOUND-SCRIPT-NOAPI’;} );

commits = _.sortBy(commits, function(c){ return c.created_at ? c.

created_at.getTime() : 0})

var groupedByMessage = _.groupBy(commits, ’commit_msg’);

for(k in groupedByMessage) {

var commits = groupedByMessage[k];

var first = commits[0];

var firstMeta = commitsMetadata[first.uuid];

var others = commits.slice(1);

for(var i = 0; i < others.length; i++) {

var dup = others[i];

dup.$writeThrough = true;

var reason = "bySha";

if(first.commit_id !== dup.commit_id) {

reason = "byMsg";

dupsByMsg++;

var dupMeta = commitsMetadata[dup.uuid];

if(firstMeta && dupMeta) {

var authorMatch = _.isEqual(firstMeta.commit.author, dupMeta.

commit.author);

if(authorMatch){

reason += "_Author";

}

var statsMatch = _.isEqual(firstMeta.stats, dupMeta.stats);

if(statsMatch) {

reason += "_Stats";

}

firstNames = firstMeta.files.map(function(f){return f.

filename});

dupNames = dupMeta.files.map(function(f){return f.filename});

firstNames.sort();

dupNames.sort();

var filesNamesMatch = _.isEqual(firstNames, dupNames);

if(filesNamesMatch) {

reason += "_FilesNames";

Page 72: Por Irineu Martins de Lima Moura - UFPE...Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring

B.2. DUPLICATE DETECTION SCRIPT 71

} else {

var subFilesNamesMatch = _.difference(firstNames, dupNames).

length === 0 || _.difference(dupNames, firstNames).length

=== 0;

if(subFilesNamesMatch){

reason += "_SubFilesNames";

}

}

}

} else {

dupsBySha++;

}

dup.duplicate_of = reason + ":" + first.$sheetRowNum + ":" +

first.commit_id;

dup.$writeThrough = undefined;

duplicates++;

}

}

return {

duplicates : duplicates,

dupsBySha : dupsBySha,

dupsByMsg : dupsByMsg,

}

}

Page 73: Por Irineu Martins de Lima Moura - UFPE...Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring

727272

CSurveys

C.1 First phase survey email template

Hello %recipient_name%,\n\

\n\

We are academic researchers from the Informatics Center [1] of

the Federal University of Pernambuco [2] and we are currently

performing a study on GitHub to understand how developers

change their code to improve software energy efficiency.\n\

In this study we analyze commits that we deem to be

\"energy-aware\" and while doing so we have found a

commit (%commit_link%) that you have authored/committed.

It would be of great help if you could answer the following

questions regarding the aforementioned commit:\n\

\n\

- Would you be able to describe your intention when you

performed this commit?\n\

- Did the change yield actual energy savings? Why do you

believe this happened?\n\

\n\

Thank you!\n\

\n\

[1] http://www2.cin.ufpe.br/site/index.php\n\

[2] https://www.ufpe.br/english/\n\

\n\

Kind regards,\n\

Irineu Moura\n\

MSc Student at CIn/UFPE

Page 74: Por Irineu Martins de Lima Moura - UFPE...Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring

C.2. SECOND PHASE SURVEY EMAIL TEMPLATE 73

C.2 Second phase survey email template

Hello %recipient_name%,\n\

\n\

We are academic researchers from the Informatics Center [1] of

the Federal University of Pernambuco [2], Brazil, and we are

currently performing a study on GitHub to understand how

developers change their code to modify the energy consumption

of a software system.\n\

In this study we analyze commits that we deem to be

\"energy-aware\", that is, any commit that refers to a source

code change where developers intentionally modify, or aim to

modify, the energy consumption (or power dissipation) of a

system or make it easier for other developers or end users

to do so.\ While conducting this study, we have found a

commit (%commit_link%) that you have authored/committed.

It would be of great help if you could answer the following

questions regarding the aforementioned commit:\n\

\n\

- Do you confirm that the commit above is indeed energy-aware?\n\

- Would you be able to describe your intention when you

performed this commit?\n\

- Did you notice any difference on energy consumption

footprint on the target system? How did you observe that?

Have you used any energy consumption profilling tool/technique?\n\

\n\

\n\

Additional notes:\n\

- If you do not wish to participate, simply do not reply to

this e-mail. There will be no follow up.\n\

- Your e-mail address was obtained by looking at the author

and/or committer e-mail provided in the Git commit that

was pushed to GitHub.\n\

- If you would like to know more about our work, please take

a look at our MSR’2015 paper [3]. Do no hesitate in contacting

us if you have further questions.\n\

\n\

Thank you!\n\

\n\

Page 75: Por Irineu Martins de Lima Moura - UFPE...Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring

C.2. SECOND PHASE SURVEY EMAIL TEMPLATE 74

[1] http://www2.cin.ufpe.br/site/index.php\n\

[2] https://www.ufpe.br/english/\n\

[3] http://gustavopinto.github.io/lost+found/msr2015.pdf \n\

Kind regards,\n\

Irineu Moura\n\

MSc Student at CIn/UFPE

Page 76: Por Irineu Martins de Lima Moura - UFPE...Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring

757575

DCommits

C0 fix power consumption issue caused by ill-defined power state at startup. Accessed:2015-03-19, https://github.com/kugel-/rockbox/commit/73732f406ebd3e5b85a70c8f7ff60fd26144551a

C1 Collect a sample only if GPU is active. Accessed: 2015-03-19, https://github.com/showp1984/bricked-pyramid-3.0/commit/045915561261cfdd985fe908

af46247facc7674d

C2 Interrupt and Power Saving. Accessed: 2015-03-19, https://github.com/barney-parker/Arduino-Countdown-Timer/commit/9178594298dbf216a241c7d

bfd5ecd2889588133

C3 enable power save. Accessed: 2015-03-19, https://github.com/samm-git/device_alcatel_OT993D/commit/d108dccc376b62e79ab5800ceac6a3d5a6acb

07e

C4 Tuned Govs to more agressive power save. Accessed: 2015-03-19, https://github.com/dorimanx/initramfs3/commit/a8d84e287a9c27828577d940f66d6a12

45706157

C5 enable power saving after boot. Accessed: 2015-03-19, https://github.com/CyanogenMod/android_device_sony_montblanc-common/commit/bd032afd36

ab0bd45c105239550d0d97d46bcf33

C6 Tune for battery life. Accessed: 2015-07-29, https://github.com/edoko/Air_Kernel-Mako/commit/f46988222af840ac5e7936e57f4c0cc352457f2d

C7 reduce battery usage : RCU_FAST_NO_HZ ON. Accessed: 2015-07-29, https://github.com/boa19861105/BOA-M7_U/commit/6c51746b38557a73beb7189553

1e147d58252ebc

C8 Save power with long-latency stall in cpu_relax(). Accessed: 2015-07-29, https://github.com/riscv/riscv-linux/commit/68e21e687fb9f587dc7361bab7b8d

f34c4337625

Page 77: Por Irineu Martins de Lima Moura - UFPE...Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring

76

C9 Change the default parameters to increase the TP. Accessed: 2015-08-01, https://github.com/TI-OpenLink/wl12xx/commit/9b68d5904a146d831908d5302ec

3c328e4a199c0

C10 Disable HWSUP mode and save power. Accessed: 2015-08-01, https://github.com/ch33kybutt/kernel_cmplus_tuna/commit/342dd821bed948b15c40de7

276094e6e011bd379

C11 Including some power savings modes. I doubt they amount to much. Accessed: 2015-08-01, https://github.com/pfriedel/FiveMilSpire/commit/4c3652781307a60e6e2bbc5bce0ca5c53ad95c11

C12 notification leds: use only one thread. Accessed: 2015-08-01, https://github.com/milaq/android_kernel_lge_p940/commit/d030acbaf9ee681eb44407e3

5d1c582d5ac8ee4e

C13 Revert "pegasusq: more tweaking for battery life". Accessed: 2015-08-01, https://github.com/simone201/neak-gs3-kernel/commit/82584c9987696930e94

cede05585cb0a016bae8f

C14 Tuned abyssplug for more power save!. Accessed: 2015-08-02, https://github.com/dorimanx/Dorimanx-SG2-I9100-Kernel/commit/fe6fc634b61f68306a

8929b464e7d6ce1ff24a90

C15 Shutdown S2W on screen ON, and activate on OFF. Accessed: 2015-08-02, https://github.com/dorimanx/initramfs3/commit/b423b7c7a8afecbeb95a0441

acc8e8d3fdc45211

C16 Reduce voltage to LCD screen to save power.. Accessed: 2015-08-02, https://github.com/ryrzy/LG-D802-G2-_Android_KK_D802_v20b/commit/cebcdec402

18cd3faa51a0e9a5a76082e417c77e

C17 Revert cpufreq_pegasusq.c: mincrease cpu_rate_up to make it. Accessed: 2015-08-02,https://github.com/dorimanx/Dorimanx-SG2-I9100-Kernel/commit/f6

66ffece32ab713b8c0e4f353020eea7c395a28

C18 Added more controls to STWEAKS. read more.. Accessed: 2015-08-02, https://github.com/dorimanx/LG-G2-D802-Ramdisk/commit/7aa281ce6f799add58

e4b7dc9944f20a0c0673a5

C19 AdaptiveX set to default governor - best for power saving as it only. Accessed: 2015-08-02, https://github.com/RAZR-K-Devs/android_kernel_motorola_omap4-common/commit/4b3f259eb0f97fab24ac3b18667a67c18c33476b

C20 drivers: cpufreq: ktoonservative: tune for being more balanced and sa.... Accessed:2015-08-02, https://github.com/RAZR-K-Devs/android_kernel_motorola_omap4-common/commit/e25e040cfe71ae99bb6d66dec37d4ad118da920d

Page 78: Por Irineu Martins de Lima Moura - UFPE...Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring

77

C21 Intelli-Plug: Add sysfs toggle for screen-on-hotplug enable/disable. Accessed: 2015-08-02, https://github.com/RAZR-K-Devs/android_kernel_motorola_omap4-common/commit/f669098b73ceaef7d2360bbdab56e1d542844f93

C22 Settings: Wireless Power Saver.. Accessed: 2015-08-02, https://github.com/OmniKang/android_packages_apps_Settings/commit/06922d4ef1ea6b7a09

c1ba3086cbea174a119b35

C23 Added Adaptive CPU Governor.. Accessed: 2015-08-02, https://github.com/k2wl/i9105Sammy/commit/e4a7fb4237b65cec9ca909c218331a41814cabac

C24 rcu: Reduce cache-miss initialization latencies for large systems. Accessed: 2015-08-02, https://github.com/dorimanx/Dorimanx-SG2-I9100-Kernel/commit/9cb185b7e5d8e49f0725d4ca21e47ab7b7fdafea

C25 Revert "d2: defconfig: Enable power efficient workqueues by default". Accessed:2015-08-02, https://github.com/SyNtheticNightmar3/android_kernel_samsung_d2/commit/fc9af4351aba65b6467f5c8a61db64e5196d7105

C26 add power efficient workqueue toggle. Accessed: 2015-08-02, https://github.com/Evisceration/android_packages_apps_DeviceControl/commit/139f4

c45217155483545d2455ea69dd2e6a1d467

C27 OOM fixe to allow smooth RAM MNG + horrable mistake fix!. Accessed: 2015-08-02,https://github.com/dorimanx/initramfs3/commit/6a8172c80617c240a

fdeb1d07c9b0c396473e706

C28 Add tweaks for save battery. Accessed: 2015-08-02, https://github.com/markolino631/android_device_lge_e720/commit/ae191ad8982e99df408b728

8edd13d8286567c85

C29 no power saving in X.. Accessed: 2015-08-02, https://github.com/lmio/liox/commit/c12e2c5bdcca28a06b5c33245ddf5f93bb528969

C30 power saving disabled by default. Accessed: 2015-08-02, https://github.com/chrishamm/PKGBUILDs/commit/bcd7c2d346983d8e5b416e62f2ad4d235805a

897

C31 Turns off screen power saving.. Accessed: 2015-08-03, https://github.com/lomogoto/ConfigFiles/commit/ea6bf6ea591e2c94e5094dbcf90f94e5

C32 msm: kgsl: Remove lowest power level. Accessed: 2015-08-03, https://github.com/Team-Blackout/Blackout-Monarudo/commit/ed0c17410b24d265d2d11

80351fc5adac4a49932

C33 cpufreq: boost the sampling rate on touch event. Accessed: 2015-08-03, https://github.com/CyanogenMod/android_kernel_htc_msm8960/commit/694447e

65dd4af2af7193021ab67c4cad91ff412

Page 79: Por Irineu Martins de Lima Moura - UFPE...Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring

78

C34 Prevent scanning during DHCP process. Accessed: 2015-08-03, https://github.com/CyanogenMod/android_frameworks_base/commit/c70ebdae9f02d133

504874bb8d0ed842c4e812c2

C35 Semi working - sensors read out, but bad radio.. Accessed: 2015-08-03, https://github.com/Teslafly/emonTH/commit/659afda362c0e0a23dc36d6f56fa0aa

b83812c91

C36 Rest: disable USB power save for fatclients and thinclients.. Accessed: 2015-08-03, https://github.com/opinsys/puavo-users/commit/1bfb72030a7265bfe1

8b9a623b2bf1218834d4fd

C37 Disable Auto Power Saving.. Accessed: 2015-08-03, https://github.com/alobo/SerialGSM/commit/c616b950bd144e9e4c32c337d6429d059ef12b94

C38 added basic powersaving, after we’ve got details of lock and sats. Accessed: 2015-08-03, https://github.com/jamescoxon/APRS_Projects/commit/894f32276ff5826c6292f42aaf313c0003a18262

C39 frameworks/base: Enable LPA for music stream only.. Accessed: 2015-08-03, https://github.com/CyanogenMod/android_frameworks_base/commit/283df8c

a2e87c89ddb9952957319191281eba818

C40 ondemandplus governor: remove adaptive timer_rate logic. Accessed: 2015-08-03, https://github.com/burstlam/leanKernel/commit/4bfcac6cd2be96ef48

9aabee96301efe0789e111

C41 fixed a problem whereby the location manager. Accessed: 2015-08-03, https://github.com/Loxrie/iOSLunchTimer/commit/c4cbf999eb53b7485763b46b17

10b2e00a023595

C42 Added more comfortable UI to the ATtiny24 lamps. Need more FLASH!. Accessed:2015-08-03, https://github.com/madworm/ATtiny_projects/commit/412bbd3a53c990bbbc2d65c9d189b55e4a7c73b1

C43 inhibit screensaver / power saving mode on OS X when FS-UAE is running. Accessed:2015-08-03, https://github.com/FrodeSolheim/fs-uae/commit/209b089048c4bffd11b23ac6c2a9a3b3c8de39b1

C44 set default cpu mode to performance. Accessed: 2015-08-03, https://github.com/CyanogenMod/android_device_asus_tf300t/commit/0208fba05ba42bb

76bf83a74a52afb14134c4f4e

C45 Small energy saving fix, fix for drawing message text. Accessed: 2015-08-04, https://github.com/GreatEmerald/Arcomage-Clone/commit/e97711e960e1323

7b6189585ac1933f9470ab8ed

C46 Removed power saving feature and mute notifications feature. Accessed: 2015-08-09,

Page 80: Por Irineu Martins de Lima Moura - UFPE...Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring

79

https://github.com/ksiazkowicz/lightbulb/commit/dfa59c62fb8e436

cfaae99423787dad97c9d76ce

C47 Disable accelerometer sensor while in-call and screen UI is off.. Accessed: 2015-08-03,https://github.com/burstlam/android_packages_apps_Phone/commit/

1e509fe6d08f66d7fab47e01c632a6bd181afb34

C48 Import of Power saving/management project.. Accessed: 2015-08-03, https://github.com/adein/Tasker/commit/ef6669ee93562d4f14b44fca1b38f787102

9caf1

C49 Following ’try 2 core minimum’ - this time with sleep. Accessed: 2015-08-03, https://github.com/bedalus/nexus4/commit/50bc75cdb09efbb1db7241cbcadb

cb92bc0104b4

C50 services: change default sampling interval to -1. Accessed: 2015-08-03, https://github.com/CyanogenMod/android_frameworks_base/commit/5d89ef90996

531a535b3a79a521bb9517cd978d5

C51 fix ts uart pm. Accessed: 2015-08-03, https://github.com/milaq/android_device_hp_tenderloin/commit/e6968626bc8eb1e62a68a0710e182cc57b78

027c

C52 Hide expanded dialog when screen is off. Accessed: 2015-08-03, https://github.com/ThePlayground/android_frameworks_base/commit/538a512d6b0099

ad6b8411d1722f6e097504f044

C53 remove infinite animation that triggers continious style recalculatio. Accessed: 2015-08-03, https://github.com/cagerton/foundation/commit/f8d9ec651fff130d05e242f25b5e0a2815a5a7fd

C54 Import of Power saving/management project.. Accessed: 2015-08-03, https://github.com/janl/dotjs/commit/0ff6020ae975f11289fdf0b89685bcd1358d9

0b7

C55 fixed wrapping timers at 4.294 seconds. Accessed: 2015-08-07, https://github.com/desalesouche/kernel_huawei_u8220/commit/13549799684cbf29200f

c183529bcf9de9a33622

C56 Fix for battery consumption. Accessed: 2015-08-07, https://github.com/akafugu/vetinari_clock/commit/a849db9196834a595644ea51af6e8c090e9db

058

C57 Set CORE off-mode voltage to 0¨. Accessed: 2015-08-07, https://github.com/ch33kybutt/kernel_skipjack_tuna/commit/ba52df5486229823fc56bd90d

94f1e45cbbdbb88

C58 Make all pins inputs with resistors to minimize power consumption. Accessed: 2015-

Page 81: Por Irineu Martins de Lima Moura - UFPE...Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring

80

08-07, https://github.com/theapi/CctvBlindfoldBundle/commit/781b3e3f45943c8ab96c2fca6be0dff3ca3df0bd

C59 Initial power saving sleep modes. Sleeps after 120 sec. Accessed: 2015-08-09, https://github.com/rickshory/AVRGreenlogger/commit/c43ac3bafb2fee3e5

133cdd67ca506d34e08c9a4

C60 Add some checks and a power saving timeout. Accessed: 2015-08-09, https://github.com/sconklin/rotorcontrol/commit/1804b9706007c836ea6308ffb1

b26ae082735126

C61 energy saving in loop. Accessed: 2015-08-09, https://github.com/Bagception/MiniMeLibrary/commit/eaa5820226f7d1e608091b8b0919791a971845c5

C62 Improved location sampling logic. Accessed: 2015-08-07, https://github.com/renlijie/TripTrack/commit/55a0e515037b2669ad941c011628c4feabcb80

c3

C63 Added reverse mode, reduced battery usage, UI changes. Accessed: 2015-08-09, https://github.com/rec0de/tappr/commit/3cdbdb17c0ceb00d96de24c64b2

984546f8a83f3

C64 Remove syntastic. Accessed: 2015-08-09, https://github.com/rweald/.vim/commit/399796625d7688128332f37faa0737e04b1bc823

C65 power saving tweaks. Accessed: 2015-08-09, https://github.com/openenergymonitor/emonTH/commit/e80faebc0f61f1f13cc7703c36c2fdc655606bfc

C66 Disable accelerometer and compass on Android to save battery.. Accessed: 2015-08-09,https://github.com/EbenezerEdelman/inferno/commit/fc3d1a29e9f09

f3a8cd3cea6e5f697e41908e82e

C67 Increase wifi scan interval to save battery. Accessed: 2015-08-09, https://github.com/androidarmv6/android_device_samsung_cooper/commit/f54b436a0

097cf423149eb84a0b6268625213d1e

C68 Changed wifi.supplicant_scan_interval to 80 in order to save battery. Accessed: 2015-08-09, https://github.com/SakuraDroid/android_device_samsung_codina/commit/fd6b9c816c9b7ee2e40733d682ed0f4119bf8f1f

C69 removed initial change that had a lower wifi scan interval. Accessed: 2015-08-09, https://github.com/pcarenza/android_device_motorola_msm8960-common

/commit/9f4228009a678336de7de1c5ddc2733ad4b0563c

C70 Lots of changes and bug fixes. Accessed: 2015-08-09, https://github.com/OpenSensing/funf-v4/commit/b109d4bd71df191c414eab61ef57e00265f2afdb

C71 Increased sync frequency to 8 hours intervals. Accessed: 2015-08-09, https://github.com/oxplot/contactphotosync/commit/73a79b2f64801f847deebf7f

Page 82: Por Irineu Martins de Lima Moura - UFPE...Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring

81

cc7630e6c3fff0d1

C72 dont always run it, fire it via alarmmanager. Accessed: 2015-08-09, https://github.com/NamelessRom/android_packages_apps_DeviceControl/commit/8

3bb13bfd705b9200d68c28daf2f9acbcbdb5f55

C73 removed interval timer from JS to improve battery life. Accessed: 2015-08-09, https://github.com/spikeheap/pebble-emoncms/commit/f30ec58fb5ae543a

e73d3b1141d17fb0ee903ab1

C74 Tweaked ViewThread and TimerThread so that they actually susped. Accessed: 2015-08-09, https://github.com/iyulaev/tacotime/commit/a07d7e043cf520f172b5dc8b9cc3aa211dad4465

C75 Disable Tor when there’s no network connectivity – to save battery. Accessed: 2015-08-09, https://github.com/rod-hynes/ploggy/commit/3b23f5b087fe4c57c72a68a1bff537ee3e9263fe

C76 Power HAL: disable KSM scanning when screen is off. Accessed: 2015-08-09, https://github.com/steven676/android_device_bn_encore/commit/7bfc699

5e84a1f1e3f380d63d8219d9be610a1f6

C77 Fix to save battery by using GPS less.. Accessed: 2015-08-09, https://github.com/alecdhuse/Topo-Hawk-Mobile/commit/826765093bb208c8192f2dfeea5

64bfa4cb9ea87

C78 Added reverse mode, reduced battery usage, UI changes. Accessed: 2015-08-09, https://github.com/rec0de/tappr/commit/3cdbdb17c0ceb00d96de24c64b2

984546f8a83f3

C79 server: start cne service. Accessed: 2015-08-09, https://github.com/CyanogenMod/android_frameworks_base/commit/a9ff5a97e3c7de3438b19bbe0a4

3d28f53695edd

C80 TEST: WCD9310: Use power efficient workqueue.. Accessed: 2015-08-09, https://github.com/yseras/SGS4-3.13/commit/7618d681692c6ae1508bd981c7bc

837b8f2bc334

C81 defconfig: Enable hdmi_toggle, enable thermal_sys module, thermal_fra. Accessed:2015-08-09, https://github.com/RAZR-K-Devs/android_kernel_motorola_omap4-common/commit/3f2329812930888d37c55dc616f6a8356ff95852

C82 Updated circuit from build test, added sleep. Accessed: 2015-08-09, https://github.com/jerwil/sleep-coach-ATTiny/commit/3aacaadcd5107643e8e3cd5

df8869c6f2aa886f5

C83 sched: set mc_power_savings=2. Accessed: 2015-08-09, https://github.com/jfdsmabalot/kernel_samsung_msm8974pro/commit/35288c36fbb499cde734

Page 83: Por Irineu Martins de Lima Moura - UFPE...Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring

82

9776a2da36dda1604d5

C84 Changed TXPOWER configuration to only accept values between. Accessed: 2015-08-09, https://github.com/nfi/contiki/commit/8474151f1965c626c84c17d298a90cb4887ec35e

C85 Disable bluetooth quick switch-on/off as it doesn’t apply to this device. Accessed:2015-08-09, https://github.com/djp952/android-platform-device-samsung-atlas/commit/e52e4bf4cbedab2013c32211868f7e6c5831b24f

C86 Radical simplification of memory access patterns. Accessed: 2015-08-09, https://github.com/cbuchner1/CudaMiner/commit/c4c67b51ce90eed0938403165

4b771587c1b0295

C87 Reduce Wifi voltage for power savings.. Accessed: 2015-08-09, https://github.com/Metallice/android_kernel_samsung_espresso10/commit/34f473801

9a9e04c882ffa05bed1b40b81017c51

C88 Tuned abyssplug for more power save!. Accessed: 2015-08-09, https://github.com/dorimanx/Dorimanx-SG2-I9100-Kernel/commit/fe6fc634b61f68306a

8929b464e7d6ce1ff24a90

C89 AdaptiveX set to default governor.. Accessed: 2015-08-09, https://github.com/RAZR-K-Devs/android_kernel_motorola_omap4-common/commit/4b3f259

eb0f97fab24ac3b18667a67c18c33476b

C90 Implemented proper bitmap drawable caching.. Accessed: 2015-08-09, https://github.com/nhasan/Airports/commit/1474bd2ea24ed682caea9ba055185d2

b79315a17

C91 optimize battery usage -> disable 3g+wifi on boot. Accessed: 2015-08-09, https://github.com/flotre/LocateMe/commit/2147f7cfa590c23cf7a88e4e18fd0

2d14a0e0dfc

C92 charger: suspend when not animating. Accessed: 2015-08-09, https://github.com/IceColdJelly/android_system_core/commit/4f13f2925d345d7d3ea5

03c38664311cf08f4493

C93 Reverted font since the bigger one didn’t fit.. Accessed: 2015-08-09, https://github.com/TheChrisPratt/CSTPebble/commit/2e3a83bff52b5cb99a494fa88

4ee6ef5b3e87cc0

C94 Only affecting mobile (where speed increases & saving battery are helpful) & Safari.Accessed: 2015-08-09, https://github.com/tomByrer/velocity/commit/c38c2b0c28eda3425b0881863f131387c841fd35

C95 Add backlight power saving.. Accessed: 2015-08-09, https://github.com/nasenatmer/ftw/commit/614dd1e2615d0300e3a4bd7066f19bdb3e568c9c

Page 84: Por Irineu Martins de Lima Moura - UFPE...Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 M929m Moura, Irineu Martins de Lima Mining energy – aware commits: exploring

83

C96 Change minimum brightness and dim brightness to 0.. Accessed: 2015-08-09, https://github.com/indiumindeed/frameworks_base/commit/3ad1d01e51ec2b

7ac0f4c7ca803e063a5f6400cb

C97 mako: backlight: apply customized backlight LUT for power saving. Accessed: 2015-08-09, https://github.com/fozzil4/android_kernel_mako/commit/735ce0fb5f58f76dd42cf724294758cb41831b2f