Call Graph Simplification for Software Performance Analysis

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Call graph analysis in large software systems becomes complex and difficult due to the exponential growth of call sequences, making it challenging to detect and fix performance degradation issues, especially when multiple call graphs are involved, and performance regression testing is inefficient.

Innovation Solution

A method for simplifying call graphs by determining nodes representing resource consumption, eliminating minor nodes based on exclusive and inclusive values, and applying a simplification factor to output a reduced call graph, which can also merge and compare multiple call graphs for improved analysis.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Measurement precision

If call graph analysis is performed on large software systems, then comprehensive performance analysis is achieved, but the complexity of analysis becomes exponentially difficult

Engineering Contradiction:

Improveperformance analysis comprehensivenessVSAvoidcall graph complexity

Core Design Contradiction:

Measurement precisionVSDevice complexity

Solution Approach 1:

The patent segments the complex call graph into multiple simplified call graphs by dividing the software system into modules or components. Each simplified call graph represents a subset of functions and calling relationships, making analysis more manageable while maintaining overall system coverage through hierarchical or modular structure

Inventive Principle:

Principle #1Segmentation

Solution Approach 2:

The patent extracts and eliminates less important nodes from the call graph based on criteria such as resource consumption thresholds, calling frequency, or impact on performance. This extraction process removes redundant information while preserving critical performance-related nodes, reducing complexity without sacrificing analysis quality

Inventive Principle:

Principle #2Taking out (Extraction)

2Reliability

If multiple call graphs are analyzed for performance degradation, then gradual performance issues can be detected, but the analysis difficulty becomes exponentially difficult

Engineering Contradiction:

Improveperformance degradation detectionVSAvoidanalysis difficulty

Core Design Contradiction:

ReliabilityVSDifficulty of detecting and measuring

Solution Approach 1:

The patent merges multiple simplified call graphs into a comparative analysis framework that identifies performance degradation patterns. By aligning corresponding nodes and edges across different call graphs, the system can detect gradual performance issues through comparison while keeping each individual graph simple and manageable

Inventive Principle:

Principle #5Merging (Combining)

Solution Approach 2:

The patent applies different analysis depths and detail levels to different parts of the call graph based on their importance. Critical performance-affecting nodes are analyzed in detail across multiple call graphs, while less important nodes receive simplified treatment, allowing reliable degradation detection without uniform complexity throughout

Inventive Principle:

Principle #3Local quality

3Productivity

If performance regression testing is performed with multiple code changes, then quality assurance is improved, but detecting critical performance degradation becomes difficult

Engineering Contradiction:

Improvequality assurance efficiencyVSAvoidperformance degradation detection accuracy

Core Design Contradiction:

ProductivityVSMeasurement precision

Solution Approach 1:

The patent performs preliminary simplification of call graphs before conducting performance regression testing. By pre-identifying and eliminating nodes that are unlikely to cause performance degradation, the system prepares a focused analysis framework that maintains quality assurance coverage while improving the ability to detect critical performance issues among multiple code changes

Inventive Principle:

Principle #10Preliminary action

4Manufacturing precision

If incremental performance tests are performed by applying every single change, then performance regression is identified, but the process becomes very tedious

Engineering Contradiction:

Improveperformance regression identificationVSAvoidanalysis time

Core Design Contradiction:

Manufacturing precisionVSLoss of time

Solution Approach 1:

The patent applies partial action by performing incremental performance tests only on selected subsets of changes rather than every single change. By using the simplified call graph structure to identify which changes are most likely to impact performance, the system achieves adequate performance regression identification without the tedium of exhaustive testing of all possible change combinations

Inventive Principle:

Principle #16Partial or excessive action

Data Source

PatentUS9367426B2Call graph simplification/comparison and automatic initial suspects finding of performance degradations

Publication Date: 2016.06.14 SAP SE

AI summary

In one embodiment, a method for call graph analysis is provided. The method includes determining a plurality of nodes in a call graph. The plurality of nodes represent resource consumption of functions of a software program executed in a software system. A simplification factor is determined. A first set of nodes in the plurality of nodes is then eliminated based on exclusive values for the plurality of nodes, inclusive values for the plurality of nodes, and the simplification factor. An inclusive value for a node is a first amount of resources consumed by the node and any descendent nodes of that node. An exclusive value for the node is a second amount of resources consumed by the node. A simplified call graph is output including a second set of nodes in the plurality of nodes. The second set of nodes does not include the eliminated first set of nodes.