Saxon

Legacy ID: #9778782 Legacy Poster: Michael Kay (mhkay)

Do you have evidence that this change would make a measurable performance difference?

Legacy ID: #9778970 Legacy Poster: Bartek  (bkowal)

Hi, We haven't done any comparative performance tests. I can only say that we did tests with ~160 tps, with 3 transformations for each message. When doing thread dumps, we observed plenty of threads waiting on synchronization on ClassLoader.loadClass() caused by loading the emitter/receiver class. Thanks, Bartek

Legacy ID: #9785718 Legacy Poster: Michael Kay (mhkay)

Saxon doesn't in fact go to the ClassLoader to load this class each time, because it's one of the classes that is known to the DynamicLoader in package net.sf.saxon.trans. It does do a reflexive instantiation of the class using getInstance(), but I'd be surprised if doing that once per transformation is really a measurable overhead. So I don't understand why you should observe threads waiting on ClassLoader.loadClass() with this class unless you customized something.

Legacy ID: #9785721 Legacy Poster: Michael Kay (mhkay)

So I don't understand why you should observe threads waiting on ClassLoader.loadClass() with this class unless you customized something. Or you would see it on 9.1, which doesn't have this optimization.

Legacy ID: #9785935 Legacy Poster: Bartek  (bkowal)

Hi, Yup, I'm using 9.1.0.8. I've just checked 9.3.0.4 sources and you're right. It's no longer a problem: protected void registerKnownClasses() { knownClasses.put("net.sf.saxon.serialize.MessageEmitter", MessageEmitter.class); //knownClasses.put("net.sf.saxon.java.JavaPlatform", JavaPlatform.class); // not available on .NET knownClasses.put("net.sf.saxon.Configuration", Configuration.class); } Thanks, Bartek