Race-Catcher-Overhead

Race Catcher™ Overhead

The effect of the Race Catcher™ on the targeted process execution speed is highly optimized and, taking in consideration the nature of analysis it performs, this overhead is relatively small.

Additionally, for the purpose of further controlling the overhead, you have an option of using the Race Catcher™ agent in the following two modes: 

• Production mode, where overhead is controlled to stay close to or under 5%.   

              or

• Test mode, where overhead is not controlled and will depend on the target process algorithm.

Test mode is the one that assures to never miss any experienced race condition.

The Production mode performs the analysis by "time probes" in order not to overload the CPU.

Still, being able to run Race Catcher in production allows much better coverage of possible conditions that were not experienced in test environment only, and, as such, it allows for continuously improving applications reliability.

Both modes would never provide "false positive" analysis results.

In the following, a process running without the Race Catcher™ agent is called below "Black Box mode" process, vs. Race Catcher™ enabled mode.

Startup Time:  Please note that the application startup time is not accounted in the overhead calculation above, and in many cases it will represent approximately 2x to 5x times of the Black Box startup time. An application that  takes 1 second to start in Black Box mode may take 2 to 5 seconds to start it in  Race Catcher™ enabled mode.  The extra time here is taken by the automatic instrumentation of the loaded classes.

Please keep in mind the following characteristics of the multithreading conditions analysis.

As there is no such thing as "error free code" - that simply can never be proven - there are also no 100% tested applications.  That is particularly the case in the multithreading conditions analysis.  Under different alignment of the process threads, caused by different stress, different input values, and consequently different execution paths of the target process algorithm, different multithreading issues will be observed.

For that reason, it is best to never stop the analysis even after the target application is shipped.

Having Race Catcher™ agent to be a part of the shipped application would ensure that the issues not experienced in the test would still be caught and analyzed, even if they only manifest themselves in production environment and under a production stress.  

In some cases, the Production mode of Race Catcher™ enabled processes will have overhead that is almost undetectable, while the benefits of constant monitoring of application reliability are very significant.