Redundancy-free analysis of multi-revision software artifacts

Abstract

Researchers often analyze several revisions of a software project to obtain historical data about its evolution. For example, they statically analyze the source code and monitor the evolution of certain metrics over multiple revisions. The time and resource requirements for running these analyses often make it necessary to limit the number of analyzed revisions, e.g., by only selecting major revisions or by using a coarse-grained sampling strategy, which could remove significant details of the evolution. Most existing analysis techniques are not designed for the analysis of multi-revision artifacts and they treat each revision individually. However, the actual difference between two subsequent revisions is typically very small. Thus, tools tailored for the analysis of multiple revisions should only analyze these differences, thereby preventing re-computation and storage of redundant data, improving scalability and enabling the study of a larger number of revisions. In this work, we propose the Lean Language-Independent Software Analyzer (LISA), a generic framework for representing and analyzing multi-revisioned software artifacts. It employs a redundancy-free, multi-revision representation for artifacts and avoids re-computation by only analyzing changed artifact fragments across thousands of revisions. The evaluation of our approach consists of measuring the effect of each individual technique incorporated, an in-depth study of LISA resource requirements and a large-scale analysis over 7 million program revisions of 4,000 software projects written in four languages. We show that the time and space requirements for multi-revision analyses can be reduced by multiple orders of magnitude, when compared to traditional, sequential approaches.

On the usage of pythonic idioms

“…Magic methods are naturally detected by looking for function definition nodes with the appropriate name. To make these detections, we utilized LISA, a framework for performing large-scale software analysis on abstract syntax trees [2]. We analyzed the most recent revision of all 1,000 projects, totalling 178,735 files containing 38,505,577 lines of Python code.…”

Software provenance tracking at the scale of public source code

“…Depending on the intended application and field of use, provenance can be looked at various granularities [4,13]. On the finest granularity end of the spectrum, tracking the origin of programming building blocks like functions, methods or classes, code snippets, or even individual lines of code (SLOC) and abstract syntax trees (AST) [4], is useful when studying coding patterns across repositories [5,17]. On the opposite end, at the coarsest granularity, tracking the origin of whole repositories is useful when looking at the evolution of forks [7,28,42,53] or project popularity [8].…”

Evo-Clocks: Software Evolution at a Glance

“…Underlying our method for visualizing graph evolution is an idea that originally relates primarily to the efficient computation of metrics and other analyses over the entire history of large software projects, although the technique applies to any kind of versioned graph, as we discuss in section V-D. To this end, we present a graph compression algorithm and numerous techniques for reducing redundancies when analyzing multiple revisions of the same project in previous work [5]. A central concept in that work is the idea of a "revision range".…”

“…Consequently, each revision to be measured is analyzed individually in a laborious, resource-intensive, and slow process. Research shows that more than 95% of data is redundantly analyzed when discounting the multi-revision nature of software and that, all other factors being equal, analyzing revisions individually can be over 50 times slower [5]. Short of expensively parallelizing the workload, a fairly simple improvement is to analyze revisions incrementally, recomputing values only in artifacts where changes occur.…”

“…But given that changes are usually small and localized, for example, at the method level, this still involves significant redundant computation. (5) shows how a method count is computed and stored. The top-level class, for example, counts two methods in the first revision, and then five in the second and third revisions, for which this value is stored only once.…”