Community
Participate
Working Groups
A long time ago, I got in the habit of instrumenting EventTable so that I could track down responsiveness problems. The idea is that if a listener takes too long to process an event, then it should be noted. Unfortunately, this isn't a permanent feature in SWT, so it is hard for others to use this technique. They either have to know what code to change, or find and apply a patch to SWT. I'm proposing a mechanism similar to the current debug flags that Platform UI uses. This way, we could hook it up to the tracing options mechanism. This way, turning on this kind of debugging is as easy as modifying a launch configuration. I'll attach a patch.
Created attachment 16134 [details] Patch to "org.eclipse.swt" The creation of PRETTY_PRINT_NAMES table in EventTable is perhaps overkill. It's nice because people who don't know SWT intimately (like me) don't tend to know the event type constants by heart. If you don't want this, then it could be removed and only the numeric event type printed. (You need to know the event type so you know which method on a SWTEventListener is going to be called by TypedListener.)
Created attachment 16135 [details] Patch to "org.eclipse.ui" Adds two options to the ".options" file.
Created attachment 16136 [details] Patch to "org.eclipse.ui.workbench" Takes the two options and pushes them into SWT display when we create it.
If SWT applies this patch, then could you please punt the bug back to Platform UI when you're done? (So we can apply our patches....)
Looks interesting. Patching the event table will only gather statistics for untyped Listeners. Perhaps a standard typed listener collection class should be added and used by the custom controls and the other components of SWT. This class could also be instrumented. VI, SN and SSQ to evaluate the patch to figure out how this kind of functionality can be embedded in SWT.
This would make a big difference to the performance instrumentation that we are going to turn on during M6 and M7. We have noticed some Java editor operations taking a long time on keystrokes and we need to investigate them.
Adding my name to the cc list as we are now tracking performance issues more closely. Please remove the performance keyword if this is not a performance bug.
It's a good idea that fell off a cliff. Since it involves API, we can't really make changes for 3.1 ... however, we might be able to make available patched versions of these classes for performance work by attaching them to this bug report in the same way that Doug has done. My thinking in the long term is to add API to all filters to run either before or after an event, rather than add custom profiling API. An application that is interested in profiling would hook both filters and maintain a stack.
Re comment #8: "Since it involves API, we can't really make changes for 3.1" Changes that add new, non-breaking API, specifically to fix performance issues, can still be made with the approval of one PMC team member.
*** This bug has been marked as a duplicate of bug 360052 ***
