Community
Participate
Working Groups
20040413 When you close a java editor on StyledText it takes 9% of the time (274ms in my trace) to dispose of the keybindings for the editor. STEPS 1) Open StyledText 2) Profile closing it. Profile to follow
Created attachment 19994 [details] Trace of profile
Using the sampling profiler in OptimizeIt, it took 920ms to close the editor (PaneFolder$3.close). Of this, 91ms was in KeyBindingService.dispose. This is approximately 10% of the time to close the editor. This does not consider the time to activate another part. I'll try commenting out the KeyBindingService.dispose method to see if it affects the total time to execute a close. That is, I'm going to try to make sure that the profiler isn't adversely influencing the results.
With KeyBindingService.dispose ------------------------------ 601ms, 287ms, 370ms, 245ms, 213ms, 377ms, 265ms, 257ms, 212ms, 276ms Mean = 310.3ms Without KeyBindingService.dispose --------------------------------- 464ms, 263ms, 188ms, 237ms, 232ms, 232ms, 238ms, 212ms, 227ms, 224ms Mean = 251.7ms So, we see about a 19% reduction in the total time it takes to close an editor. This is the best we can hope for.
There are three blocks of time involved. The first is MenuItem.setText(...). I believe I've reduced the number of such calls significantly over 3.0, but I'll double-check to make sure that there can't be any further reductions. (Previously, we would update all; now we just update those that have changed.) The second block is the MissingResourceExceptions, which is Bug 82914. The third block is just data-pushing syntax I can't find a way of reducing. For example, iterating over a map. There is a Display.getActiveShell() in there, but I think I decided that was impossible to avoid to maintain 3.0 compatibility. If something can be done about the first block, then I'll approach it in this bug. Otherwise, I'll leave Bug 82914 to cover the rest of the stuff that might change.
It is possible to change MenuItem.setText() to compare the two strings before doing the actual OS-level work. This results in the following numbers: 294ms, 176ms, 242ms, 304ms, 333ms, 321ms, 264ms, 365ms, 215ms, 393ms Mean = 290.7ms
In talking with Billy Biggs, he said that MenuItem.setText checks for the existing text on Windows XP and Motif. It does not do this check on Linux GTK+, which costs us a small amount of performance. If Platform SWT does not implement a check for Linux GTK+, please re-assign back to Platform UI so that we can work around this deficiency.
Fixed > 20050420 on GTK+, still need to fix Carbon...
Fixed > 20050421 on Carbon
Thanks.
