A Study on Optimizing Execution Time and Code Size in Iterative Compilation

Memory safety violations such as buffer overflows are a threat to security to this day. A common solution to ensure memory safety for C is code instrumentation. However, this often causes high execution-time overhead and is therefore rarely used in production. Static analyses can reduce this overhead by proving some memory accesses in bounds at compile time. In practice, however, static analyses may fail to verify in-bounds accesses due to over-approximation. Therefore, it is important to additionally optimize the checks that reside in the program. In this article, we present PICO, an approach to eliminate and replace in-bounds checks. PICO exactly captures the spatial memory safety of accesses using Presburger formulas to either verify them statically or substitute existing checks with more efficient ones. Thereby, PICO can generate checks of which each covers multiple accesses and place them at infrequently executed locations. We evaluate our LLVM-based PICO prototype with the well-known SoftBound instrumentation on SPEC benchmarks commonly used in related work. PICO reduces the execution-time overhead introduced by SoftBound by 36% on average (and the code-size overhead by 24%). Our evaluation shows that the impact of substituting checks dominates that of removing provably redundant checks.

Download Full-text

Analysis of the influence of register file size on energy consumption, code size, and execution time

IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems ◽

10.1109/43.959862 ◽

2001 ◽

Vol 20 (11) ◽

pp. 1329-1337 ◽

Cited By ~ 17

Author(s):

L. Wehmeyer ◽

M.K. Jain ◽

S. Steinke ◽

P. Marwedel ◽

M. Balakrishnan

Keyword(s):

Energy Consumption ◽

Execution Time ◽

Register File ◽

File Size ◽

Code Size

Download Full-text

On the correlation between testing effort and software complexity metrics

10.7287/peerj.preprints.27312 ◽

2018 ◽

Author(s):

Adnan Muslija ◽

Eduard P Enoiu

Keyword(s):

Embedded System ◽

Execution Time ◽

Test Cases ◽

Code Size ◽

Software Complexity ◽

Test Execution ◽

Complexity Metrics ◽

Cyclomatic Complexity ◽

Testing Effort ◽

The Relationship

Software complexity metrics, such as code size and cyclomatic complexity, have been used in the software engineering community for predicting quality metrics such as maintainability, bug proneness and robustness. However, not many studies have addressed the relationship between complexity metrics and software testing and there is little experimental evidence to support the use of these code metrics in the estimation of test effort. We have investigated and evaluated the relationship between test effort (i.e, number of test cases and test execution time) and software complexity metrics for industrial control software used in an embedded system. We show how to measure different software complexity metrics such as number of elements, cyclomatic complexity, and information flow for a popular programming language named FBD used in the safety critical domain. In addition, we use test data and test suites created by experienced test engineers working at Bombardier Transportation Sweden AB to evaluate the correlation between several complexity measures and the testing effort. We found that there is a moderate correlation between software complexity metrics and test effort. In addition, the results show that the software size (i.e., number of elements in the FBD program) provides the highest correlation level with the number of test cases created and test execution time. Our results suggest that software size and structure metrics, while useful for identifying parts of the system that are more complicated, should not be solely used for identifying parts of the system for which test engineers might need to create more test cases. A potential explanation of this result concerns the nature of testing, since other attributes such as the level of thorough testing required and the size of the specifications can influence the creation of test cases. In addition, we used a linear regression model to estimate the test effort using the software complexity measurement results.

Download Full-text

On the correlation between testing effort and software complexity metrics

10.7287/peerj.preprints.27312v1 ◽

2018 ◽

Author(s):

Adnan Muslija ◽

Eduard P Enoiu

Keyword(s):

Embedded System ◽

Execution Time ◽

Test Cases ◽

Code Size ◽

Software Complexity ◽

Test Execution ◽

Complexity Metrics ◽

Cyclomatic Complexity ◽

Testing Effort ◽

The Relationship

Software complexity metrics, such as code size and cyclomatic complexity, have been used in the software engineering community for predicting quality metrics such as maintainability, bug proneness and robustness. However, not many studies have addressed the relationship between complexity metrics and software testing and there is little experimental evidence to support the use of these code metrics in the estimation of test effort. We have investigated and evaluated the relationship between test effort (i.e, number of test cases and test execution time) and software complexity metrics for industrial control software used in an embedded system. We show how to measure different software complexity metrics such as number of elements, cyclomatic complexity, and information flow for a popular programming language named FBD used in the safety critical domain. In addition, we use test data and test suites created by experienced test engineers working at Bombardier Transportation Sweden AB to evaluate the correlation between several complexity measures and the testing effort. We found that there is a moderate correlation between software complexity metrics and test effort. In addition, the results show that the software size (i.e., number of elements in the FBD program) provides the highest correlation level with the number of test cases created and test execution time. Our results suggest that software size and structure metrics, while useful for identifying parts of the system that are more complicated, should not be solely used for identifying parts of the system for which test engineers might need to create more test cases. A potential explanation of this result concerns the nature of testing, since other attributes such as the level of thorough testing required and the size of the specifications can influence the creation of test cases. In addition, we used a linear regression model to estimate the test effort using the software complexity measurement results.

Download Full-text