Community
Participate
Working Groups
Build ID: 20090619-0625 I've currently moved from eclipse 3.4 to eclipse 3.5 and I'm experiencing a huge performance penalty when using (live) validation. Especially when doing lots of modifications in one single EMF transaction, the live validation that is performed afterwards takes about 99% of the entire operation runtime. Operation runtime: + eclipse 3.4: about 10 seconds + eclipse 3.5: about 300 seconds Performance analysis show that almost all runtime is spent on testing if debugging is enabled (Tracing.shouldTrace invokes Plugin.isDebugging()). While in eclipse 3.4, Plugin.isDebugging() just returned a boolean field value, in eclipse 3.5 the debug options are queried which causes runtime-consuming security checks (in fact, almost all time is spent in AccessController.checkPermission). See also bug 258705, which caused the modification of Plugin.isDebugging(). Some profiling data: This call tree shows that most of the validation time is spent on calling Trace.entering and Trace.exiting (98.1%): http://project-management.at/others/eclipse/Call_Tree_TransactionImpl_validate.html The same call tree again but a little bit more expanded (the page is static and clicking on the small 'plus' icons doesn't work...): http://project-management.at/others/eclipse/Call_Tree_TransactionImpl_validate_expanded.html And now the real cause of this performance problem: Plugin.isDebugging http://project-management.at/others/eclipse/Call_Tree_Plugin_isDebugging.html
Created attachment 142352 [details] patch that caches the isDebugging flag and invalidates the cache on changes This patch caches the Boolean indicating whether tracing is enabled. In addition, a DebugOptionsListener is registered that invalidates this cache as well as the debug options cache if any debug options change. Please note that I've verified that this patch fixes the performance bug, but I'm not sure concerning the cache invalidation as I have not idea how to change the debug options at runtime.
Hi Mario, I'll verify the patch. Thanks !
Created attachment 142366 [details] Testcase for the patch Testcase which shoul be green, if the patch would have worked.
Mario, The patch you provided seems fine, however there seems to be a bug in Plugin.isDebugging/setDebugging. The problem looks like a platform bug to me. I'll try to clarify whether this is a platform bug.
bug 284397 has been created and this bug has been marked as depending on it.
Created attachment 142407 [details] Patch and testcase slightly changed patch contributed by Mario and testcase. The patch works, if the patch for bug 284397 will be commited.
Maybe you should synchronize on cachedOptions in method invalidate() too.
Fix has been submitted to head. I removed the DebugOptionsListener from EMFModelValidationPlugin.Implementation interface. The test case will follow as soon as bug 284397 has been fixed. Untill bug bug 284397 is fixed, the plugins can not be put into debugging mode anyway. I'll leave the bug as ASSIGNED until I can submit the test case. @Mario: great thanks for the contribution.
Since the fix was also pushed back to Galileo, updating the target milestone.
This bugfix seems not to be part of galileo-modeling-SR1. Unfortunately it prevents us from migrating our software to galileo. Is there any chance that it will be fixed in SR2?
I'll downport the fix for SR2
From the comments and file history this seems to have been fixed by 606c71684750b0a38ba169110761f126d93b796b.
