DevPartner

It took me quite a while to come up with a bug story for January. My inspiration finally settled on a future bug, i.e. a topic that I predict will trigger a support case in the future. One of the key problems in general that plagues engineered systems is units. Very simple mathematical errors can creep into engineering computations if units and unit conversions are not taken into account properly. Many of our customer applications rely on proper units handling, and since DevPartner data ultimately affects engineering decisions based on customer code choices, it is worth our effort affix accurate and proper units to reported analysis data.

I had a case years ago were units were left off a chart, leaving the data representation ambiguous. The chart is a Pareto analysis within DevPartner Java performance analysis. Here is a snapshot of that chart:

This chart aims to show timing profiler variable values for Java methods depicted along three dimensions as “bubbles.” How far right a bubble is shows how slow it is. How high up the bubble is shows how many times the method ran. How big the bubble is shows the accumulation of all CPU usage in that method and all its callees. The bubbles are alive and clickable, so you can drill down into the raw data values for each one. Notice however that there are no units on any axes. A highly intrepid user filed a customer care case against this chart, stating that by computing the Pi * R Squared area for his bubbles, he found they didn’t render proportionally to match the underlying data values. Fortunately, there is ample in-line-help around this chart to explain the “relative” nature of the three variables, not so much that they were absolute figures. Indeed, there remains the possibility for confusion, especially when you are facing an engineering decision about which methods you want to invest energy into streamlining and by how much.

This month we unveil another chart, the new activity gauge added in DevPartner Studio 10.6 going Beta this month. Like the Pareto chart above, the activity gauge shows a live metric, but it’s not so a much a measure of end user code being scrutinized for analysis, rather its showing the activity excited by the target application from within BoundsChecker’s analytical core. All of the DevPartner runtime analysis features operate by injecting an appropriate in-process core library into the target application. The activity gauge samples an internal counter inside BoundsChecker’s “Weasel” patching, hooking, and indirection module. The more active the target application at exciting patching and allocation logic inside BoundsChecker’s internal code, the higher and “faster” the graph metric will be displayed, especially over sustained periods of activity.

From a style perspective, the strip chart intentionally resembles the Windows Task Manager CPU performance graph. I think the X axis units are quite evident as a time series with per-second resolution. The Y axis however shows only a numeric value, and the graph range resizes appropriately as activity values in the graph flows and ebbs. Here is the crux of “the bug”, or at least potential for a future support ticket: what is the unit of measure for “Activity” as depicted in this stripchart? From an engineering units perspective, we felt it would be far too wordy to state that Activity is the monotonically increasing sum of all Weasel profiler core invocations that imply tracked allocations or API patches and indirections. In fact, it is really the first derivative of that value with respect to time, since we are graphing the rate of change of that monotonically increasing sum.

While accurate, that label is certainly a mouthful. What happens in the physical word when a new form of measure requires a handy, compact, single word unit label? The gifted scientist or engineer who concocted the observable donates her name as the unit! Think of Hertz (1/s), Curies (3.7 * 10^10 disintegrations/second), Newtons (kg*m/s^2), and Ohms (kg * m^2 /(s ^3 * A ^2)). I suggested to the team that we honor Dennis Ritchie again (recall how we dedicated DPS 10.5.3 to him in October) and call these activity rate units “Ritchies”. Since Rick and Ergin are the implementers of the activity gauge feature, that initial idea got quickly adjusted to “Rickies”. Ergin got jealous of Rick hogging the spotlight, so we experimented with “Papo-Salihs” and “Salih-Papos”, neither of which seemed gripping. I threw in “WWUs”, which is a completely made-up unit that stands for Weasel Work Units. In the grand scheme of things, this chart can indeed probably live on without a hard unit or scale, since it is a relative value that autoscales. However, anything that exposes internal operation cries out for pinning hard values, since eventually we’ll want to compare runs, determine penetration distance into apps, measure idle phases, etc., all of which could be tallied through creative use of this simple metric. I guess I’ll need to wait and see if an intrepid user takes the bait and files a care case against this once DevPartner Studio 10.6 goes generally available. Until then, just be sure to keep a handle on your own units!