It's very frequent operation - look for a component inside of an XML schema.
Now it is implemented with a simple cycle. It works well with small amount of components.
But in case of big amount it becomes a problem.
The problem has been found with HL7 schema where there > 1000 components on the root level.
It seems the most realistic that a schema can have huge amount of components only at the root level.
So it is suggested applying optimization to the root level only.
The idea of optimization is to build the TreeMap index of root components with the component's name as a key.
It can be required to build and rebuild the index time after time. But it looks reasonable anyway because
the share of write requests is going to remain much smaller then read requests.
The index approach has to be used automatically based on a threshold amount of root components.
Fixed in trunk
The last change set corrects mistake I did because of another issue #169510
The fix contains new code and related JUnit tests
Integrated into 'main-golden', will be available in build *200908041401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Log: #169515 - It's necessaryto indexing root components of a shchema model in some cases
Verified with JUnit tests + verifying different BPEL projects
The fix has been ported into the release67_fixes repository.
Verified by Michael Nazarov.