Project

Profile

Help

Default MessageReceiver

Added by Anonymous over 13 years ago

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

I took a look at how Controller instantiates a MessageReceiver. I analyzed 9.1.0.8 source code, but it seems that the impl in the latest ver is similar. I think that in a situation when classname is not overridden (the default one is used), it'd be more optimal to just instantiate it directly and not load the class each time a new instance is needed. Just call new net.sf.saxon.serialize.MessageEmitter(). With the current impl threads wait on ClassLoader.loadClass() which is synchronized. Bartek


Replies (5)

Please register to reply

RE: Default MessageReceiver - Added by Anonymous over 13 years ago

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

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

RE: Default MessageReceiver - Added by Anonymous over 13 years ago

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

RE: Default MessageReceiver - Added by Anonymous over 13 years ago

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.

RE: Default MessageReceiver - Added by Anonymous over 13 years ago

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.

RE: Default MessageReceiver - Added by Anonymous over 13 years ago

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

    (1-5/5)

    Please register to reply