Post as a guest Name. Email Required, but never shown. The Overflow Blog. Podcast Making Agile work for data science. Stack Gives Back Featured on Meta. New post summary designs on greatest hits now, everywhere else eventually. Related 5. Hot Network Questions. Question feed. Stack Overflow works best with JavaScript enabled.
Runtime analysis is the practice of looking at a program's behavior based on what it does when it runs. This is different from "static analysis," where you analyze program behavior by looking at its source code or high-level structure; or "crash analysis," where you look at what a program leaves behind when it fails.
Debugging is one classic example of runtime analysis: You set breakpoints, step through the program, and look at argument values and variables, all to gain an understanding of what's actually happening as the program runs. When you're debugging, you're not interested in all the possibilities of what might happen, but, rather, what really does happen. That's what separates runtime analysis from static analysis. Debugging is highly interactive and can be powerful, but it's limited in what it can show you.
That is, it's hard to identify patterns and integrate higher-level behavior when your focus is narrowed down to the size of a source line or a variable. Testing is another kind of runtime analysis: You feed in data or events and check to see that you got the right behavior from the program.
This sort of testing is the cornerstone of software quality. Still, traditional testing only shows you so much. A program can pass all its tests give the right answers and still have serious quality problems. Existing Customer? Click here for PurifyPlus Customer Registration. Click here to read about the latest release of PurifyPlus 8. PurifyPlus is a runtime analysis tool suite that monitors your program as it runs and reports on key aspects of its behavior:.
These key analysis features are all separate from the core "correctness" question: "Does it work? Runtime analysis has a place during the interactive compile-edit-debug development cycle and also in the automated builds and tests that are a key part of any project's quality plan. Runtime analysis during development and implementation During interactive development, Purify can report on memory errors before new code is committed to the project. Developers can use PureCoverage to identify areas where new tests are required.
Quantify can reveal unexpected code paths and bottlenecks early in the development cycle. Runtime analysis during automated testing When running automated builds and tests, PurifyPlus lets you monitor quality and collect metrics to ensure your project stays on track.
When your tests run under Purify without reporting any errors, you know your program is free of those memory access bugs and leaks. When running with Quantify shows that performance meets targets, you know you have not introduced bottlenecks.
And when PureCoverage reports a high level of code coverage, you know you have not introduced new blocks of code without also adding automated tests to exercise them. You can increase the quality of the runtime analysis data you collect during automated testing by using testing automation tools. Automated testing can give you a better depth of testing for a single iteration, and also help assess the impact of newly introduced changes on product quality.
If software quality drops between two consecutive iterations of the component, runtime analysis data makes it very easy to find the responsible feature or code change.
Runtime analysis for program understanding Sometimes runtime analysis isn't about correctness or quality at all.
For example, runtime analysis can help with program understanding. Quantify, in particular, can show a call graph that reveals how the pieces of a program fit together, or it can reveal surprising paths that can explain unexpected performance degradations or interactions. As noted above, PurifyPlus has three major components: Purify for memory analysis, Quantify for performance analysis, and PureCoverage for code coverage analysis.
All of these are software quality issues that can lurk in a program even if its tests all pass. Problems like this can cause expensive failures in production after you release the product. For Java and Microsoft. Problems like this can cause expensive failures in production after you release the product.
For Java and Microsoft. Net programs "managed programs" , Purify tracks memory usage and memory references so you can see where your memory bottlenecks are, see where you are holding memory you ought to release, and compare before-and-after images to detect unintended increases in memory usage "leaks" in the program. Quantify tracks program performance and calling behavior, so you can see execution flow and identify bottlenecks.
Quantify highlights code paths that take the longest, using the River of Time tm feature. In addition, Quantify lets you visualize thread execution behavior in your program. PureCoverage tracks code coverage, so you can identify gaps in your testing and areas of your program that the runtime analysis tools are not seeing.
Since Purify and Quantify only see the code that actually runs, the code coverage metrics provided by PureCoverage are critical to knowing that you are verifying and improving quality across your whole project.
PurifyPlus for Windows: A dynamic software analysis toolset for Windows application development. The following information lists the basic software requirements for using PurifyPlus for Windows. Microsoft Windows 10, base through 21H1 Microsoft Windows 8 base, 8. The major goals of debugging are to find the root cause of defects and understand application behavior. This particular view shows the source file of the examined application; the color of the line indicates the line's status after the executed test case: hit, missed, dead, or partially hit.
The code fragment in Figure 1 shows the exact path the application took when executing the switch statement on line This particular line is marked as partially hit because line hasn't been executed. Figure 1: PurifyPlus display of annotated source for the C. NET application in Visual Studio. A runtime analysis tool such as Quantify included in PurifyPlus provides thread visualization, which can assist in detecting multithreading problems by marking the state of each of the threads while debugging.
As Figure 2 shows, this allows you to examine the status of threads visually, while debugging. Figure 2: Quantify thread analysis view in Visual Studio 6. Runtime analysis tools can also detect and display performance bottlenecks. The big advantage of this approach, compared to traditional methods, is that you can get an excellent overview of the execution path as well as precise information about the number of calls to the methods involved in the scenario.
As Figures 3A and 3B show, the Call Graph in Quantify highlights a chain of calls in the most time-consuming execution path; that is the performance hotspot. The thickness of the line connecting methods is proportional to the ratio between the time or memory if you are using Purify spent in this chain of calls and the rest of the application. Figure 3A: Quantify call graph of a mixed VB. NET and C. The first step in handling memory leaks is to detect them. One very intuitive way to do this is to visualize overall memory usage and take snapshots of memory in the program under test PUT.
This lets you see potential memory leaks in the running application. This feature is available in Purify for Java and. NET managed applications. For example, if snapshots of memory usage for the component running on the server show that overall memory usage increases after each client session, then it is very likely that this component leaks memory see Figure 4. Figure 4: Overview of thread status and memory usage in Purify for Windows. Visual error detection is just the first stage of runtime analysis.
PurifyPlus is a runtime analysis tool suite that monitors your program as it runs and reports on key aspects of its behavior: How much memory does it use?
Does it leak memory? Does it contain memory access errors? How long does it take to run; where are the bottlenecks? How much of the source code is actually running?
0コメント