This is more of a semantic issue than a strictly performance issue, but with the current semantics of double-click selection in Swing it becomes a performance issue.

The problem is that native apps (on multiple platforms; I have seen the same semantics on Windows, Solaris, and Linux) perform a double-click action on the second mouse PRESS action.  Swing, on the other hand, performs a double-click action on the second mouse RELEASE action.

I originally thought that the problem was in AWT; perhaps they were not sending the correct event at the correct time.  But it is now clear that AWT does not define these semantics; they simply forward the events and let the client (Swing, in this case) decide what to do with them.   Also, I wrote a simple app that showed that Awt running on Windows uses the native Windows selection semantics (second mouse press).

The result of this difference between PRESS and RELEASE is a delay in selection that is noticeable to the user; I timed this additional time (between the mouse
press and mouse release during a simple double-click) at between 70 and 100 ms on average.

I have attached a test app TextSelection.java that shows the difference between Awt and Swing selection.  To see the difference, double-click in one of the awt text fields, but hold the mouse on the second click; note that the text is selected on this 2nd mouse press action.  Now do the same in the Swing text fields; note that the text is not selected until you finally release the mouse.
Now note the timings; I print out some simple information when interacting with the Swing frame regarding the time and 
highlighter (hacky, but I use the highlighter info to detect when the text is actually selected).  Note the time between the second mousePressed and mouseReleased; this is the additional time that it takes for Swing to select text versus a native app (or Awt, for that matter).