Please help me figure out why this thread's performance degrades over time

Question

Hello.
The code below is from a Runnable that I've tested inside a Thread operating on a TreePath array of size 1500; the array 'clonedArrayB' is this TreePath array. The code is designed to create a more stepped version of setSelectionPaths(TreePath[]) from class JTree.
The performance decrease of the thread is very rapid; this is discernible simply from viewing the println speed. When it gets to about 1400 TreePaths added to the JTree selection, it's running at roughly 1/10 the speed it started running at.
I know there's no problem with maintaining a set of selected paths of that size inside a JTree. I also know that the thread stops when it should. So it must be some operation I'm performing inside the brief piece of code shown below that is causing the performance degradation.
Does anyone have any idea what could be causing the slowdown?
Many thanks for your help. Apologies if you would have liked an SSCCE, but I very much doubt it's necessary for this. Either you can see the problem or you can't. And sadly I can't x:'o(
int indexA = 0;
public void run() {
     // Prevent use of / Pause scanner
     try {
          scannerLock.acquire();
     } catch (InterruptedException exc) {
          Gecko.logException("Scanner lock could not be acquired by expansion thread", exc);
     while (!autoExpansionComplete) {
          while (indexA < clonedArrayA.length) {
               int markerA = indexA + 10;
               for (int a = indexA; a < markerA && a < clonedArrayA.length; a++) {
                    pluginTreeA.addSelectionPath(clonedArrayA[a]);
               indexA = markerA;
               System.out.println(indexA + "," + clonedArrayA.length);
                    if (autoExpansionComplete) {
                         break;
               stop();
};

Answer 1

Well, since I've had no responses, I tried to think of other ways to speed the code up.
I'd already made nearly every tweak I know. The only additional thing I could think of was to use addSelectionPaths(TreePath[]) on a subarray of the cloned array, instead of addSelectionPath(TreePath) on the cloned array's elements, since obviously it would be fewer method calls. It has sped things up an awful lot (my new code is shown below - I've left in some things I chopped out above, so you can see exactly what I see). The problem is though, obviously an increase in initial velocity doesn't solve the problem of deceleration occurring, if you get me.
// Clone the selection arrays to non-volatile arrays for better access
// speeds
final TreePath[] clonedArrayA = selectionPathsArrayA.clone();
final TreePath[] clonedArrayB = selectionPathsArrayB.clone();
// Create a new runnable to perform the selection task
Runnable selectionExpander = new Runnable() {
     /** Position within cloned array A */
     int indexA = 0;
     /** Position within cloned array B */
     int indexB = 0;
     /** Length of subarray grabbed from cloned array A */
     int lengthA;
     /** Length of subarray grabbed from cloned array B */
     int lengthB;
     /** Subarray destination */
     private TreePath[] subarray = new TreePath[100];
     public void stop() {
          autoExpansionComplete = true;
          automatedSelection = false;
          scannerLock.release();
      * Grabs 10 blocks of each selection paths array at a time, adding
      * these to the tree's current selection and then moving to the next
      * cycle
     public void run() {
          // Prevent use of / Pause scanner
          try {
               scannerLock.acquire();
          } catch (InterruptedException exc) {
               Gecko.logException("Scanner lock could not be acquired by expansion thread", exc);
          while (!autoExpansionComplete) {
               while (indexA < clonedArrayA.length || indexB < clonedArrayB.length) {
                    // Set subarray lengths
                    lengthA = subarray.length;
                    lengthB = subarray.length;
                    // If subarray length is greater than the number of
                    // remaining indices in the source array, set length to
                    // the number of remaining indices
                    lengthA = indexA + lengthA > clonedArrayA.length ? clonedArrayA.length - indexA : lengthA;
                    lengthB = indexB + lengthB > clonedArrayB.length ? clonedArrayB.length - indexB : lengthB;
                    // Create subarrays and add TreePath elements to trees'
                    // selections
                    System.arraycopy(clonedArrayA, indexA, subarray, 0, lengthA);
                    pluginTreeA.addSelectionPaths(subarray);
                    System.arraycopy(clonedArrayB, indexB, subarray, 0, lengthB);
                    pluginTreeB.addSelectionPaths(subarray);
                    // Remember the latest index reached in source arrays
                    indexA += lengthA;
                    indexB += lengthB;
                    System.out.println(indexA + "," + clonedArrayA.length);
                    System.out.println(indexB + "," + clonedArrayB.length);
                    if (autoExpansionComplete) {
                         break;
               stop();
// Create and start new thread to manage the selection task runner
selector = new Thread(selectionExpander);
selector.start();I really can't think what could be causing the slowdown. I've done everythng I can think of to increase the velocity, such as cloning the source arrays since they're volatile and access could be slightly slower as a result.
Nothing I try gets rid of the slowdown effect though :(
- Dave