Re: Setting GUI thread priority
FutureScalper wrote:
Well, the application is a fast, near real-time Online Futures
Please do not top-post. Use trim-and-inline posting.
Scalping application, so it acquires market data, up to about 10,000
events per minute, analyzes, charts and also manages multiple
simultaneous live orders. It uses a Swing GUI hand-coded, and is
heavily optimized for high performance. A live order is "bumped" in
price to a new price, in roughly 120 milliseconds and so order
processing events are high priority for me.
So, in general, I want order processing threads to be highest in
priority, but there is one area in which I am concerned about high
priority. Maybe I'm wrong, and maybe what I really want is a non-gui
execution of Swing events but, for now, I believe these events execute
on the GUI dispatch thread.
The Swing events run on the EDT, and must.
Let's say I want a keystroke or a mouse click to affect order
processing activity. My simple understanding is that these run on the
GUI dispatch thread, which is a reasonable design decision designed to
serialize their activity.
It is necessary by the very innate nature of GUIs.
So, I want to elevate/control the execution priority of the GUI
thread, so that these events, which ultimately kick off order entry
actions, are themselves very responsive.
No, you want to make sure the order entry actions happen at a high priority,
not the GUI events. In fact, you likely do not need to mess with the
priorities at all.
I understand the concerns associated with multiple thread priorities,
and I think I've struck a reasonable balance here.
I am not sure that you do, nor that you have.
What other threads are running whose priority you wish to preempt in favor of
the GUI?
I don't actually have long-running activities on the GUI thread, so
that's not a concern.
"Long-running" is a relative term. In your case I suspect you'll get more
benefit from updating your model on a non-EDT (possibly high-priority) thread
than by changing the EDT priority.
But specifically, this was my reason for wanting to have some control
over the priority of GUI activities. The idea being that a keystroke
or mouse click should run in preference to my lower-priority NON-order
processing threads, because most of these GUI activities are designed
What are these other threads? Do they influence the GUI?
to be responsive in a chain of my highest priority events, which are
live order processing management.
So run the model that changes prices at a higher priority. Your GUI happens
for all logic, not just the priority logic, all in the EDT - one thread for
GUI service to all other non-GUI threads.
You should make the high-priority /logic/ higher priority, not the GUI.
I should add here that I stress the Java Server VM to its limits in
this application, and things are very fast, for a Java application,
that is...
I use practically every switch in the book right now, and this is a
mature application, just so you aren't thinking I'm a Newbie or
something like that.
The application runs roughly 100 threads in a process, and my primary
target platform is Windows XP or Vista using Sun's Server VM.
Server VM Runtime switches are:
<resources>
<j2se version="1.6.0+" java-vm-args=" -server -dsa
-XX:ThreadStackSize=256 -XX:CompileThreshold=50 -XX:+AggressiveOpts -
XX:MaxGCPauseMillis 0
-XX:CICompilerCount=1 -XX:+UseBiasedLocking -XX:+CMSIncrementalMode -
XX:+AggressiveHeap
-XX:+RelaxAccessControlCheck -XX:-TieredCompilation --XX:NewSize=640m -
XX:MaxNewSize=640m -XX:SurvivorRatio=16
-XX:MaxInlineSize=64000 -XX:FreqInlineSize=64000 -XX:-
DontCompileHugeMethods
-XX:+UseFastAccessorMethods -Xss192k -Xms380m -Xmx380m -Xbatch -
Xnoclassgc
-Dswing.defaultlaf=com.sun.java.swing.plaf.windows.WindowsLookAndFeel -
Dswing.metalTheme=steel
-Duser.timezone=America/New_York -Duser.language=en -Duser.region=US"/
I just don't think it's the EDT priority that should concern you. Of course I
don't really know, but do not be surprised if playing with the EDT priority
fails to help very much. If your model updates fast enough you might find
that the GUI can keep up without having to mess with priority.
In other words, be sure to test your assumptions before deploying them into
production.
For one thing, if you boost the EDT priority, it boosts for *all* GUI events,
not just the ones associated with your price changes. Instead, boost the
priority of the threads that actually handle the order price changes.
If you really want faster, switch from Vista to Linux or Solaris. Consider
multi-processor servers. With all those threads you have you should be able
to make good use of such a platform.
--
Lew