The DevPartner® product line consists of developer tools that aid in code troubleshooting and inspection. Developers, testers, and build managers can use one or more tools in their daily code, test, and verification work. Depending on what you need to achieve, different tools are available:
Our tools are combined into suites according to what you really need to do and primary languages. This allows developer, testers, and build managers to leverage the right tools for their specific role throughout code construction and validation efforts. Starting off with the base functionality in Boundschecker, you can add functionality to offer even more powerful capabilities:
| Edition | Functionality | |
|---|---|---|
 | BoundsChecker | Geared toward native C and C++ developers hunting memory and corruption problems. |
 | DevPartner VC++ Edition-BoundsChecker Suite | Geared towards native developers, but providing coverage and performance for testers. |
 | DevPartner Studio Professional Edition | Everything you need to build great C++ & .NET applications from DevPartner |
 | DevPartner Java Edition suite | Mirrors for Java the managed tools in DevPartner Studio Professional edition and works on many JVMs on Windows, Linux, and UNIX platforms. |
The table below gives a detailed view of what each suite has to offer:
Memory use in managed languages remains a tough source for bugs to hide in thanks to the garbage collector and developers’ reliance on it for all memory management chores. Even though objects may normally be disposed automatically, objects that linger, force extra garbage collections, or hoard objects semi-intentionally, can all affect system-wide application performance and scalability. DevPartner’s .NET Memory Analysis provides zero-click, one-click, and two-click interactive interfaces for studying memory use. Drill down to specific object references and allocation traces to gain comprehensive insight into which classes and which code is responsible for memory misuse.
Compilers can do a fine job of determining whether your source syntax is legally permitted within the rules of that language grammar. But can they determine when the source syntax is good? That is the realm of Code Review, which is like performing a manual code review with a bunch of people inspecting lines of source, yet with the automation power of computer assistance. Static analysis can reveal code problems in structure, design, complexity, and naming. So teams can police their own local practices and achieve design goals relative to object orientation, maintainability and readability of code, and reduction of common bug patterns. What’s more, static analysis of web applications offers scrutiny of the first tier of security vulnerability in multi-tier deployments.
Have you ever placed a bit of code in a for loop and seen how long it takes a hundred thousand times to run? That is a primitive but effective way to isolate and optimize specific routines. It can, however, also tear up the code and loses practicality in whole applications. Performance Analysis gives you the stopwatch, with precision down to single invocations of routines and lines of source code. Based on a proprietary kernel-mode driver, the timing engine inside Performance Analysis sniffs out bottlenecks at the thread level, yet presents findings in context of lines, methods, classes, and components. With the ability to quantitatively show whether CPU or I/O bounds lie at the root cause of each bottleneck, optimization strategies become clearer.
It has been stated that adding code coverage analysis to an application development practice can be the single most important quality step that a team can adopt. Code coverage indeed provides quantifiable evidence for test case execution. It also provides insight into where tests can be added, and where gaps may yet lie. DevPartner Coverage Analysis handles many types of tests, providing summary and drilldown details for source level execution counts. It remains the simplest of runtime inspections to grasp and to operate, so should be the first step in attacking code quality objectives.
BoundsChecker is the heart of DevPartner's error detection capability. It finds the root cause of many sources of application instability, including memory leaks and overlays, heap and stack corruption, overruns, and API misuse. Offering two operational modes, one with and one without compile time instrumentation, BoundsChecker provides many ways to uncover application flaws that if left unchecked could toss a critical application into fault.
Have you ever placed a bit of code in a for loop and seen how long it takes a hundred thousand times to run? That is a primitive but effective way to isolate and optimize specific routines. That technique can, however, also tear up the code and loses practicality in whole applications. Performance Analysis gives you back the stopwatch, but with precision down to single invocations of routines and lines of source code. Based on a proprietary kernel-mode driver, the timing engine inside Performance Analysis sniffs out bottlenecks at the thread level, yet presents findings in context of lines, methods, classes, and components. With the ability to quantitatively show whether CPU or I/O bounds lie at the root cause of each bottleneck, optimization strategies become clearer.
It has been stated that adding code coverage analysis to an application development practice can be the single most important quality step that a team can adopt. Code coverage indeed provides quantifiable evidence for test case execution. It also provides insight into where tests can be added, and where gaps may yet lie. DevPartner Coverage Analysis handles many types of tests, providing summary and drilldown details for source level execution counts. It remains the simplest of runtime inspections to grasp and to operate, so should be the first step in attacking code quality objectives.
Memory use in Java remains a tough source for bugs to hide in thanks to the garbage collector and developers’ reliance on it for all memory management chores. Even though objects may normally be disposed automatically, objects that linger, force extra garbage collections, or hoard objects semi-intentionally, can all affect system-wide application performance and scalability. DevPartner’s Memory Analysis provides zero-click, one-click, and two-click interactive interfaces for studying memory use. Drill down to specific object references and allocation traces to gain comprehensive insight into which packages, classes, and code is responsible for memory misuse.
The Java bytecode compiler can do a fine job of determining whether your source syntax is legally permitted within the rules of the Java language. But can the compiler alone determine when the source syntax is good? That is the realm of Code Review, which is like performing a manual code review with a bunch of people inspecting lines of source, yet with the automation power of computer assistance. Static analysis can reveal code problems in structure, design, complexity, and naming. Teams can police their own local practices and achieve design goals relative to object orientation, maintainability and readability of code, and reduction of common bug patterns. What’s more, reverse analysis of Java package structures can identify poor object oriented constructs using a model that spans your whole application—with only bytecode needed if no source is available—to address design problems that may haunt you for years as code is grown and maintained.
Have you ever placed a bit of code in a for( ) loop and seen how long it takes a hundred thousand times to run? That is a primitive but effective way to isolate and optimize specific routines. It can, however, also tear up the code and loses practicality in whole applications. Performance Analysis gives you the stopwatch, with precision down to single invocations of routines and lines of source code. Based on a proprietary kernel-mode driver, the timing engine inside Performance Analysis sniffs out bottlenecks at the thread level, yet presents findings in context of lines, methods, classes, and components. With the ability to quantitatively show whether CPU or I/O bounds lie at the root cause of each bottleneck, optimization strategies become clearer.
It has been stated that adding code coverage analysis to an application development practice can be the single most important quality step that a team can adopt. Code coverage indeed provides quantifiable evidence for test case execution. It also provides insight into where tests can be added, and where gaps may yet lie. DevPartner Coverage Analysis handles many types of tests, providing summary and drilldown details for source level execution counts. It remains the simplest of runtime inspections to grasp and to operate, so should be the first step in attacking code quality objectives.
DevPartner saves money because your developers are spending time fixing bugs instead of trying to find a needle in a haystack. That is where DevPartner's ROI can be easily measured. From our standpoint, the key to our success is customer satisfaction and that comes from our high-quality products as well as our ability to solve any problems quickly.
— Roger Andrews, Vice President and CTO, Synergex
Download Case Study
Last year, when we tried to make our system faster in some executable modules, we got five to seven times better performance based on information we received from DevPartner Studio.
— Alex Kavushansky, Software Manager, InSightec
Download Case Study
Many seemingly innocent coding practices have the potential to cause code to execute slowly. In a number of cases, individual programming techniques can be innocuous, but when aggregated they can weigh heavily on application performance. Programmers should understand the performance implications of the code they write by looking at performance analysis during unit tests and as a part of code reviews
Halting the writing of code for a period of time for a formal review is difficult in an agile process. Time is rarely allocated to stop the development process. Fortunately, virtually all of the activities done by a team code review can be automated through static source code analysis.
Deepen your understanding of how a .NET application uses memory, and what an application developer can do to improve memory management for better performance and more reliable applications.
By determining what lines of code were executed during unit tests, developers and development teams can ensure that their tests have exercised enough code to gain a level of confidence that defects have been minimized. To be truly effective, unit testing and code coverage should be used together.