This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Many users are reporting increased UI response time in BPEL diagram. This is a regression since September-November 2007 builds. My recent investigation showed that primary cause of this lags is incorrect model source implementation. Currently, EVERY time we trying to find somethin in ModelSource's lookup, method getLookup() defined at org.netbeans.modules.xml.retriever.catalog.Utilities.java:632 is being called, which calls EditorCookie.openDocument(), which in depth doing massive file system operations to determine encoding for current document. As a result a single call to lookup() method can take up to 1000ms and even more. This is not acceptable because lookup() is being called from XAMUtils.isWritable(model) method, which is being called very often.
This doesn't sound right. If there was any regression since September, we would have certainly come to know about it by now. Your investigation sounds very inconclusive to me. In any case, I'll take a look. BTW, did you really mean you found this in 5.0?
I have optimized this code. Please verify. /cvs/xml/retriever/src/org/netbeans/modules/xml/retriever/catalog/Utilities.java,v <-- Utilities.java new revision: 1.11; previous revision: 1.10
This code was not touched in a long time so I suspect some other changes elsewhere could have caused what your users are experiencing. In any case, this fix should help.
My understanding is that this regression was introduced when NB folks added Encoding property to the project last autumn. This function someway tries to build the list of roots for local file system and if you have any slow storage attached to your machine, such as network disks or floppy drives, this function takes a long time to complete. We are accessing this property indirectly when calling EditorCookie.openDocument() in _getDocument() function when construction our lookup. I will try your fix and report results shortly.
Sam, fix does not solve the problem, because ModelSource is often used as short-living object, used just to access xam model by given file object. So, caching lookup inside ModelSource does not make sense. Also it caused P1 regression, please check 126293.
The fix was made based on your description, please read it carefully. I do not see any issues on schema nor wsdl side. I suspect the usage of model source and models in bpel. If this gets you to a regression, it tells me that there is some wrong usage on your side. In general the fix is good and optimizes getLookup(). So this issue is technically fixed. Now you should find out why you're getting into a regression and IMO the problem should be somewhere else.
The caching is good but I do see another issue here though. It keeps the document in the lookup which may lead to the regression because each time the document in the lookup is same. Let me investigate further. The problem may as well be in schema and wsdl.
Ok, this fix will not work. I'll revert it back, and in this case, the openDocument call remains a problem.
Reverted caching of lookup. See http://hg.netbeans.org/main?cmd=changeset;node=e0bcbd573fc1. Also I profiled the initial issue that was reported but the openDocument() call in most cases measures few milliseconds. Please investigate further on poor application performance and UI freezes. I'm marking this as wontfix.
Sam, would you reconsider this issue in 7.0 ?
Refer to new issue 134585. *** This issue has been marked as a duplicate of 134585 ***