Default MessageReceiver

Bartek
2011-03-31
2012-10-08
  • Bartek

    Bartek - 2011-03-31

    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

     
  • Michael Kay

    Michael Kay - 2011-03-31

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

     
  • Bartek

    Bartek - 2011-03-31

    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

     
  • Michael Kay

    Michael Kay - 2011-04-01

    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.

     
  • Michael Kay

    Michael Kay - 2011-04-01

    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.

     
  • Bartek

    Bartek - 2011-04-01

    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

     

Log in to post a comment.