XML Faq improve speed suggestion.

Hmm. Yes, this could and should be added to the FAQ, or even better to the newly created XML best practice document.

Having said that, I wonder why this has such an huge effect on performance ?

I ran some profiling and I believe the issues might arise from the searchInheritance method of MarshalFramework. For me this method is called repeatedly with a class names that do not exist. Here is a stack trace of the call

Thread [main] (Suspended)
ClassDescriptorResolverImpl.loadClass(String, ClassLoader) line: 650
ClassDescriptorResolverImpl.resolve(String, ClassLoader) line: 395
MarshalFramework.searchInheritance(String, String, XMLClassDescriptor, ClassDescriptorResolver) line: 349
Marshaller.marshal(Object, XMLFieldDescriptor, ContentHandler, Marshaller$MarshalState) line: 1187
Marshaller.marshal(Object, XMLFieldDescriptor, ContentHandler, Marshaller$MarshalState) line: 1824
Marshaller.marshal(Object) line: 821
SpeedTest.main(String[]) line: 33

I think one possible bug might be near the bottom of ClassDescriptorResolverImpl.resolve. The code looks for a class descriptor class. This is not found and a ClassNotFoundException is thrown. The catch saves details but uses the className variable. I think it perhaps should use the dClassName variable instead.

Another possible problem might be the fact that a "Must call loadMapping first" exception is thrown many times. Both the resolveAllByXMLName and resolveByXMLName look at package mappings, for me these are the NULL_MAPPING static at calling getResolver always throws. Adding if ( mapping != NULL_MAPPING ) before the try/catch/swallow for both these methods seems to claw back some more time.

Here is patch. My test code took just over 18 seconds to convert 2000 objects before the patch and just over 3 seconds afterwards.

Phil, can I please ask you to attach a fully working sample (preferably relative to src/bugs) that highlights your problem initially, and which I could subsequently to add a new test case to the CTF suite ? Please have a look at http://castor.org/how-to-submit-an-xml-bug.html, if possible ...

I can't for the life of me get svn diff to create a patch for the test case. I have attached a zip file instead. I have tried to follow the guidelines, the test can be unpacked to src\bugs\xml\. The test should fail before performance.patch is applied and pass afterwards. The patch was tested against the trunk 22-Aug-06. See the README.TXT.

Appreciated, Phil. Just out of curiosity, what's the problem with the SVN diff ?

Not sure, I typed "svn diff" and nothing happened. If I cd into src\bugs\xml and type svn diff bug1508 I get bug1508 is not under version control.

You'll need to 'svn add' the new files before running 'svn diff'. And yes, this is not a bug, but a feature ... .

Unified patch against src.