By the way, this has many consequences to the code performances, and as a matter of fact, the ThreadStack will be treated differently on single- and multiple-core systems. For instance, Windows does get much more resources to synchronize on screen with Swing than a Mac OS X does. It’s my own experience about that, since I test my code both on ix86 arch and ppc arch. on the other side, single-threaded applications don’t provide the best effort on a single-core or non-HyperThreading (unlike ppc ARE obviously 2 logic-channels cpu’s) machine because system processor architectures do manage simple functions to be dispatched on both channels (if any available).
There’s a conclusion about that speciality on multi-threading, one application will get the best effort only if it launches as more threads the Stack can afford, because the more the code-logic looks like the processor(s) logic, the faster the system may compile and dispatch events to the core(s). It’s as easy to understand.
My own experiences proved that I got the best results when targeting my code structure to a multi-threaded style than focusing on single-threaded. Moreover, it looks like the Swing-Timers do not like much to coalesce their events as the actions become slower, and therefore I modified the most of my Timer-Action’s to instance a new Thread when required by sort of long processes. This is know as “coalesceing events”.
More concretely, most parts of my code are timed Events, e.g. be that function an usual send-notify a new value to a selected Object :
/** this is the action Thread to make coalesceing */
Thread myActionThreadRef;
function Object doActionOff() { // or whatever function you need
int x = this.positionX;
sendEventToObject(receiver, x);
notifyEventToObject(receiver);
return this.status;
}
javax.swing.Timer swingTimer = new javax.swing.Timer(10, new ActionListener() { public void actionPerformed(ActionEvent e){
// here's the trick I mentioned, t is instanciated to free the Swing Timer faster than usual,
//which has the advantage to manually "coalesce" as Swing does it.
if(myActionThreadRef instanceof Thread)
if(myActionThreadRef.isAlive())
return; // I don't launch the thread because there's the previous one unterminated
Thread t = myActionThreadRef = new Thread(new Runnable() { public void run() {
Object status = doActionOff();
// I never let my objects states un-logged... So here I stick to the rule.
System.out.println(status);
}});
// maybe set priority to max
t.setMaxPriority(Thread.MAX_PRIORITY);
t.start();
}});
This has speeded up to twice the application, something I’m still bringing up for the moment. :
Multi-Threading has many advantages but requires to be experienced with synchronization patterns, as a must-have. 
