Creating XmppClient needs several seconds

[Markus KARG]

I noticed that creation of XmppClient needs several seconds. This is not nice for the end user, and it is a bit weird that it is the case, as it does not perform a real lot of work, nor does it perform blocking operations. I traced performance a bit and found that the main problem seems to be creation of the JAXB context, but had not time to dig deeper.

It would be great if we could reduce creation time to under one second, as it is not nice that users have to wait four seconds for a pure in-memory operation.

[Christian Schudt]

Yes, it's the JAXBContext. Unfortunately I have no idea what to do about it. The good thing is that it's only created once, which means all following XmppClient instances are created fast.

[Christian Schudt]

You can find many articles and posts about the "JAXBContext performance issue". The general proposed solution is to create it only once and store it statically.

You can invoke XmppSessionConfiguration.getDefault() on JVM startup (maybe in a different thread) to pre-initialize the configuration (mainly the JAXBContext). Next invocation (by XmppClient) will be fast then becaue it uses the static pre-initialized singleton. Custom configurations can use setDefault().

[Christian Schudt]

I've noticed that it indeed takes around 4 seconds, but only when you are debugging with break points. Otherwise it runs much faster, on my PC it takes around 800-900ms.

Could you try that code without debugging:

long now = System.currentTimeMillis();
XmppClient xmppClient = new XmppClient("localhost");
System.out.println(System.currentTimeMillis() - now);

[Markus KARG]

Unfortunately that already IS how I measured the four seconds... :-( BTW, I am running on a dual-core @ 1.7 GHz, SSD, 12 GB RAM.

[Markus KARG]

Oh I have not read your posting carefully enough. You want me to check the XmppClient, but not the configuration.

So here is the result: * The above code needs approximately 2.9s * Creating the default configuration needs approximantely 4s. * Creating an XmppClient from the pre-created default configuration needs about 0.8s

[Christian Schudt]

How can creating the XmppClient (which includes creating the configuration) be less than only creating the configuration?

[Christian Schudt]

This is from my tests on a 5 year old MBP (no other code run before):

long now = System.currentTimeMillis();
XmppSessionConfiguration.getDefault();
System.out.println(System.currentTimeMillis() - now);

ca. 1000 ms

long now = System.currentTimeMillis();
new XmppClient("");
System.out.println(System.currentTimeMillis() - now);

ca. 1200 ms

XmppSessionConfiguration.getDefault();
long now = System.currentTimeMillis();
new XmppClient("");
System.out.println(System.currentTimeMillis() - now);

< 200 ms

The 800-900ms referred to example 1 on another machine (Windows)

Is your classpath large? Maybe the JAXBContext creation and/or XMLInputFactory.newFactory() has trouble with it?

[Markus KARG]

Christian, creating the XmppClient is faster than only creating the configuration ONLY in the described case: XmppClient is created FROM (not AFTER) pre-created configuration (i. e. new XmppClient(domain, config)).

Test results of above code: 2010ms 2244ms 220ms

Yes the classpath is pretty complex thanks to a lot of libraries (12 jars plus application and Babbler).

I assume that JAXB is not particularly well-done. As it was written in the single-core-era I doubt that it makes good use of modern concurrency tools and simply wait much too long for I/O before going on with the next task. Unfortunately that source code is not available publicly, as it is a com.sun.* class, so I cannot debug it.

[Christian Schudt]

Yes, I guess nothing much we can do about it?! I am not familiar with the internals of JAXBContext, but maybe there are other providers than com.sun (although I couldn't find any)

[Markus KARG]

Maybe we should give MOXy a shot? As it is JAXB compliant it should be simply a drop-in actually (uses services framework). Blaise Doughan developed it back in the time when Oracle was separate from Sun so actually it might be more kind of industrial-proof than former Sun's Kohsuke Kawaguchi's reference implementation? On the other hand, if MOXy would really be better, I really wonder why it was given away to the Eclipse foundation and stay with the RI in OpenJDK...? Possibly because it was never ported to Java 7 and still is f* slow?

[Christian Schudt]

I've tried MOXy once for testing purposes and it wasn't even able to unmarshall the Message class properly. Never tried it again since then. Woodstox works, but it doesn't affect JAXBContext, it only gets you another implementation from XMLIn/OutputFactory.newFactory().

[Markus KARG]

Gave MOXy a try. It's crap. Needs seven seconds instead of four, and crashes later. Seems there is simply is no solution that WE can provide.

[Christian Schudt]

Closing this because there's nothing we can do about in Babbler's code. It's the JAXBContext which takes some time. It's a known issue of JAXB.