Bug 95650 - [model] Allow lazy loading of XSD model when loading WSDL model
Summary: [model] Allow lazy loading of XSD model when loading WSDL model
Status: NEW
Alias: None
Product: WTP Webservices
Classification: WebTools
Component: wst.wsdl (show other bugs)
Version: unspecified   Edit
Hardware: PC Windows XP
: P3 enhancement (vote)
Target Milestone: Future   Edit
Assignee: Project Inbox CLA
QA Contact: Keith Chong CLA
URL:
Whiteboard: reviewed_1.5
Keywords: performance
Depends on:
Blocks:
 
Reported: 2005-05-17 16:11 EDT by Jeffrey Liu CLA
Modified: 2010-07-20 11:36 EDT (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jeffrey Liu CLA 2005-05-17 16:11:49 EDT
Performance: Allow lazy loading of XSD model when loading WSDL model.

Today, as part of loading a WSDL file (the EMF WSDL model), users will also 
get the XSD model. The initialization of EMF model are expensive and should be 
deferred as much as possible. It would be nice if we can lazy load the XSD 
model when the user actually request for it through the WSDL model, for 
example, trying to get an XSD type from a WSDL part.

Here's an use case scenario. I know that the Web services wizards use the WSDL 
model very frequently. Often times, the wizards just need to know information 
about the WSDL and not the XSD model. So lazy loading the XSD model will save 
a lot CPU cycles.
Comment 1 Jeffrey Liu CLA 2005-05-18 15:39:11 EDT
Did some performance measurements with Kihup. We have a JUnit testcase that 
use to take ~45s to run. If we defer schema loading, the same testcase takes 
~1s to run.
Comment 2 Kihup Boo CLA 2006-04-04 11:57:53 EDT
Keith,
As discussed.
I am re-assigning this defect to you.
Thanks.
Comment 3 Craig Salter CLA 2006-06-08 00:30:03 EDT
I'd really like to see hard numbers before getting into any code changes to implement this fix.  Is there a user scenario that's performing badly?  In the past we've gottensucked into the trap of improving performance for things that have very little end user impact. Keep in mind that usually these kind of changes cause many regressions and lots of additional work.
Comment 4 David Carver CLA 2008-06-28 00:19:09 EDT
Craig...an area where this can be a real bottle neck is when you deal with large industry schemas in Business to Business Scenarios.   So anything that can be done to help users in this case is a big plus.   The specifications for HR-XML, OAGi, and STAR can have many imports and includes from a base schema.   If the WSDL imports and includes multiples of these schemas, you can take a nap at times while the system cranks along until it returns you control.
Comment 5 Valentin Baciu CLA 2008-12-03 14:48:02 EST
I second Craig's oppinion: this type of change is very risky.

One other thing to consider is that the XSD EMF model's performance has been improved significantly since 2005. See  bug 154290 for example (there are others I don't have handy).