Community
Participate
Working Groups
I instrumented our Java model in order to track the number of listeners we were registering and then notifying of possible changes. This might have an impact on the overall Toolkit performance. The worskpace I used is still the same (big) one with 120 projects. As a reference, I started Eclipse 3.2.2 against the same workspace. Only 3 listeners are registered. For RAD, I performed the very same test (launch the Toolkit and do nothing), with 2 differents workbench configuration: one with only the Java perspective opened, another where I had the J2EE + Java perspectives (which sounds to me like a representative config). See the results below: Java perspective only Total number of listeners: 90 Total number of JavaReflectionSynchronizerListeners: 87 J2EE + Java Total number of listeners: 100 Total number of JavaReflectionSynchronizerListeners: 97 I then performed 4 tests, to check whether each of these listeners were notified. Test 1 - startup, no (Java) editor opened --> do nothing No ElementChangedEvent broadcast Test 2 - startup, no (Java) editor opened --> expand a Java project No ElementChangedEvent broadcast Test 3 - startup, no (Java) editor opened --> open a Java file (but do not modify content) All listeners notified (taking an average time of 10 ms / listener) Test 4 - startup, one Java editor opened --> do nothing All listeners notified (taking an average time of 10 ms / listener) So, these numerous listeners might have an impact against performance.
Can this be addressed within Europa time frame ?
Hi Phillipe, Can you please give more help on this, I opened the VE with a breakpoint on the constructor of JavaReflectionSynchronizer and only one was created by the VE. Can you give a stack trace of the code where you think VE is doing too much work please ? Best regards, Joe
(In reply to comment #2) Joe, as discussed, this issue was discovered in RAD. With a stand alone Eclipse and the 120 projects workspace, no issue. With RAD, opening the same workspace, the issue appears. Observed behavior is as if a JavaReflectionSynchronizer listener is added for each single Java project. Please also note that depending on which perspective are active at startup, the number of listeners is different.
Joe, assuming no VE open editors and such, and the fact that this manifest itself only with RAD, it is likely that WTP performs some JEM operations which brings up BeanInfo into the picture.
This happens on any project that uses JEM. WTP uses JEM on many different projects, so each project will get a reflection synchronizer.
(In reply to comment #5) Gilli, Richard, do you consider this is expected behavior or are we facing a bug? Assuming this is a bug: 1 listener per project that uses JEM might impact overall performance in case of big wks.
For now this is expected behaviour. It is a major change to do otherwise. Each project needs its own listener because each project has a different set of classes that are to be reflected. There may be overlap, but then there may not be. In fact for the same class, depending on the classpath in the project, there may be a different reflection result depending on what project the class is in. Even if we reduced it to one listener the effect is the same because that one listener would need to do all of the actions for each individual project that was previously done by each listener. So there would not be much, if any, net gain.
(In reply to comment #7) See item #4 bug 157660#c0
(In reply to comment #8) See item #4 bug 157660's description
