I've been hacking away at this SOPI assessment tool. It is a Swing app using Quicktime for Java and the Swing Application Framework.
My first pass is to make it work. I tend to follow with a make it good, and then a make it right pass. In each pass I try to write code which is easy for the next poor person to follow. This means a lot of comments when the variable names don't help, lots of logging, lots of feedback to the end user and all that stuff. Actually I'll punt on make it right if I don't think that the next joe or jane in the organization will ever have a chance to look at the code.
So I spent a few hours, post refactoring, wondering where I had sunk the boat. All of a sudden the Quicktime movies started shuddering to a halt as the questions were being presented. I was sure I had introduced some kind of thread starvation. The end of movie handlers were still working fine, the testee could record new movies in response, but there was no guarantee that the next movie would complete.
After serial reversions I was back to looking at the data itself. As it turns out I had mis-rendered a revision to the first Quicktime movie used in the assessment. It was vastly larger then my other test cases.
As a result it was eating all the memory I had allocated to the IDE - and its spawned child processes in the debugger.