Hi Jason,
Jason H wrote:
> Hi Folks,
>
> Does anyone know any tricks to speed up XStream initialization when
> launching via javaws? Via javaws creating a new XStream instance takes
> over a minute, but via regular java it takes less than a second.
>
> This is the code:
>
> logger.log(Level.INFO, "Initializing XStream");
> xstream = new XStream();
> logger.log(Level.INFO, "Done initializing XStream");
>
> This is the output when running via javaws (showing it took 1 minute and 4
> seconds in this case):
>
> Feb 11, 2013 10:01:24 AM FileBackedCacheImpl initializeCache
> INFO: Initializing XStream
> Feb 11, 2013 10:02:28 AM FileBackedCacheImpl initializeCache
> INFO: Done initializing XStream
>
> I'm running 64-bit win 7 using 64-bit JAVA JDK 1.7.0_13 with a fast
> computer.
>
> The potentially relevant portions of my JNLP file:
>
> <security>
> <all-permissions/>
> </security>
>
> <resources>
> <j2se version="1.7+" java-vm-args="-ea" initial-heap-size="256m"/>
> <jar href="lib/MediaTaggerClient.jar" main="true"/>
> <jar href="lib/jmf.jar"/>
> <jar href="lib/mediaplayer.jar"/>
> <jar href="lib/xstream-1.4.3.jar"/>
> <jar href="lib/xmlpull-1.1.3.1.jar"/>
> <jar href="lib/kxml2-2.3.0.jar"/>
> <property name="sun.java2d.d3d" value="true"/>
> </resources>
>
> Here is a screenshot of a partial netbeans profiling session (I couldn't
> attach at time 0, but was able to attach a few seconds in). It looks like
> XStream#setupConverters is taking a long time, and particularly the call
> to ClassLoder#loadClass:
>
> [image: Inline image 1]
That's really a lot. However, I have no experience with Java Webstart. It
looks though, as if you start from a file that includes anything (like an
ear or a war). Also it seems that it is executed with an active
SecurityManager.
How does JNLP work? An application server will normally explode a web app
into a temporary directory and run it from there, because what you actually
have is a ZIP inside a ZIP file. For JNLP it depends what happens when the
classloader has to locate a class on its path. If it starts to decompress
the stuff on-the-fly then this will be a very expensive operation. Try to
deliver the JNLP as uncompressed jar. Does it have an effect?
We had once a similar situation where a self-contained jar was built with
Maven1 uberjar plugin. Unfortunately one dependency was the weblogic client
(~40MB) and the application suddenly took more than 30mins to start :-/
Note, that you have to initialize XStream only once (synchronized), you can
use the same instance for (un-)marshalling from multiple threads.
> The call to XStream#fromXML also seems pretty slow, at 8 seconds (its a
> very small XML file):
>
> [image: Inline image 2]
You're using the generic XmlPullFactory here. It will also lookup all
available XmlPullParser implementations in the classpath. Just use the
KXml2Driver directly (you may then drop the xmlpull.jar on top) or use
directly the StaX implementation of the JDK (SjsxpDriver).
Cheers,
Jörg
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
