Tim Pokorny (![[info]](http://l-stat.livejournal.com/img/userinfo.gif){kind=small} soporificfrog) wrote,@ 2006-05-13 16:19:00 |
|
Pondering Profiling
I’ve been profiling various aspects of jaRTI for a little while now. Today I was attempting to hunt down an apparent memory leak. As it turns out, the leak seems to be in Middlesim, not jaRTI itself. I had been using Middlesim so I could quickly whip up testing federates in minutes rather than hours. However, while searching high and low for the cause of the leak, I decided to run some of the tests I’ve been using while building jaRTI itself, tests which are written in pure HLA.
The result pleased me very much. The screenshot below (click on it for a larger version) shows some various piece of information about the test run I did. CPU usage is irrelevant as the JVM is running jaRTI and two federates at the same time as fast as it possibly can, so naturally this will chew up every last available cycle in an effort to get things over and done with ASAP.
The graph to take real notice of is the middle one. It shows heap allocation and in previous iterations it just continued to rise at a steady pace, indicating that there were objects that were not being collected (because something, somewhere was still holding on to a reference to them). For those of you who are curious, you can see a screenshot of what the capture looked like in those situations here. When removing the leaking Middlesim from the equation, we get a nice, steady graph like the one in the screenshot below.
As a developer, seeing something like this really makes you feel good. While you can make all kinds of guesses regarding the internal behaviour of your applications, there is nothing like the feeling of satisfaction you get from being able to validate that it is acting as desired and not being naughty.
PS. Big cheers to YourKit for granting an open source license to jaRTI for their awesome profiler.
Comments Here
I’ve been profiling various aspects of jaRTI for a little while now. Today I was attempting to hunt down an apparent memory leak. As it turns out, the leak seems to be in Middlesim, not jaRTI itself. I had been using Middlesim so I could quickly whip up testing federates in minutes rather than hours. However, while searching high and low for the cause of the leak, I decided to run some of the tests I’ve been using while building jaRTI itself, tests which are written in pure HLA.
The result pleased me very much. The screenshot below (click on it for a larger version) shows some various piece of information about the test run I did. CPU usage is irrelevant as the JVM is running jaRTI and two federates at the same time as fast as it possibly can, so naturally this will chew up every last available cycle in an effort to get things over and done with ASAP.
The graph to take real notice of is the middle one. It shows heap allocation and in previous iterations it just continued to rise at a steady pace, indicating that there were objects that were not being collected (because something, somewhere was still holding on to a reference to them). For those of you who are curious, you can see a screenshot of what the capture looked like in those situations here. When removing the leaking Middlesim from the equation, we get a nice, steady graph like the one in the screenshot below.
As a developer, seeing something like this really makes you feel good. While you can make all kinds of guesses regarding the internal behaviour of your applications, there is nothing like the feeling of satisfaction you get from being able to validate that it is acting as desired and not being naughty.
PS. Big cheers to YourKit for granting an open source license to jaRTI for their awesome profiler.
Comments Here
