Profiling XStream

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Profiling XStream

cowwoc
Hi,

     My application has two possible startup states:

- No configuration file is found, using the default settings and
generate a new configuration file on shutdown

- Configuration file is found, read objects using XStream's
ObjectInputStream.readObject()

     I have noticed that when a configuration file has to be loaded by
XStream, it takes 1.7 seconds for a 70k file. An extra 1.7 seconds
startup time is a major problem for my client-side application because
it translates into an increase by 37% and is very noticable. And this is
only with a relatively small configuration file, so I worry what happens
as it grows.

     I tried using JProfiler to track down what is bogging down the CPU
but all I see is:

ObjectInputStream.readObject():397 invoking
CustomObjectInputStream.readObjectOverride() invoking
XStream$2.readFromStream():66 invoking
XStream.unmarshal():774 invoking
XStream.unmarshal():500 invoking
ReferenceByXPathMarshallingStrategy.unmarshal:521
TreeUnmarshaller.start:12
ReferenceByXPathMarshallingStrategy.convertAnother:99
TreeUnmarshaller.convertAnother:39
[... goes on and on ...]

     At no point is any of my code being invoked as far as I can see (in
the form of readResolve() etc). Is there any way for you guys to profile
XStream to optimize it further or suggest ways for me optimize the
configuration file loading process? Is this a normal loading time for 70k?

Thank you,
Gili
--
http://www.desktopbeautifier.com/
Reply | Threaded
Open this post in threaded view
|

RE: Profiling XStream

Peter Van Caeseele
Is this configuration file only used by you and your app?  If so have you
considered using an alternate method like a properties file or object
streaming (you may want to benchmark these as well)?  I suspect you are
seeing the load and initialization time of the XStream engine and associated
XML parser and the time wont increase (much) as your config file grows.
Maybe I'm wrong - it could be object creation overhead depending on the
composition of your config file.  It should be easy enough to test.  

In the first scenario have you measured how long it takes to write the new
config file (assuming XStream hasn't been invoked previously)?  How does
your shutdown time compare to the startup time and why would they differ?
Have you thought about distributing a default config file so the user always
suffers the initial load time (not the ideal solution but should answer the
question of whether it's the users or you that notice the lag - could you
"hide" it or distract them with a splash or a progress bar)?  

If speed is REALLY the issue then there are faster ways to handle it no
matter how much they optimize XStream although not as convenient I'm sure.

Peter



-----Original Message-----
From: Gili [mailto:[hidden email]]
Sent: Thursday, December 29, 2005 12:03 PM
To: [hidden email]
Subject: [xstream-user] Profiling XStream

Hi,

     My application has two possible startup states:

- No configuration file is found, using the default settings and
generate a new configuration file on shutdown

- Configuration file is found, read objects using XStream's
ObjectInputStream.readObject()

     I have noticed that when a configuration file has to be loaded by
XStream, it takes 1.7 seconds for a 70k file. An extra 1.7 seconds
startup time is a major problem for my client-side application because
it translates into an increase by 37% and is very noticable. And this is
only with a relatively small configuration file, so I worry what happens
as it grows.

     I tried using JProfiler to track down what is bogging down the CPU
but all I see is:

ObjectInputStream.readObject():397 invoking
CustomObjectInputStream.readObjectOverride() invoking
XStream$2.readFromStream():66 invoking
XStream.unmarshal():774 invoking
XStream.unmarshal():500 invoking
ReferenceByXPathMarshallingStrategy.unmarshal:521
TreeUnmarshaller.start:12
ReferenceByXPathMarshallingStrategy.convertAnother:99
TreeUnmarshaller.convertAnother:39
[... goes on and on ...]

     At no point is any of my code being invoked as far as I can see (in
the form of readResolve() etc). Is there any way for you guys to profile
XStream to optimize it further or suggest ways for me optimize the
configuration file loading process? Is this a normal loading time for 70k?

Thank you,
Gili
--
http://www.desktopbeautifier.com/

Reply | Threaded
Open this post in threaded view
|

Re: RE: Profiling XStream

cowwoc

        My mistake. Turns out I was not including the command-line "-ea" in
JProfiler but I was doing so in my IDE so the profiler was not noticing
that the performance drop is actually due to some of my assert
statements. XStream does increase loading times, but it turns out it's
really not as bad as I thought it was. Sorry for the false alarm.

Gili

Peter Van Caeseele wrote:

> Is this configuration file only used by you and your app?  If so have you
> considered using an alternate method like a properties file or object
> streaming (you may want to benchmark these as well)?  I suspect you are
> seeing the load and initialization time of the XStream engine and associated
> XML parser and the time wont increase (much) as your config file grows.
> Maybe I'm wrong - it could be object creation overhead depending on the
> composition of your config file.  It should be easy enough to test.  
>
> In the first scenario have you measured how long it takes to write the new
> config file (assuming XStream hasn't been invoked previously)?  How does
> your shutdown time compare to the startup time and why would they differ?
> Have you thought about distributing a default config file so the user always
> suffers the initial load time (not the ideal solution but should answer the
> question of whether it's the users or you that notice the lag - could you
> "hide" it or distract them with a splash or a progress bar)?  
>
> If speed is REALLY the issue then there are faster ways to handle it no
> matter how much they optimize XStream although not as convenient I'm sure.
>
> Peter
>
>
>
> -----Original Message-----
> From: Gili [mailto:[hidden email]]
> Sent: Thursday, December 29, 2005 12:03 PM
> To: [hidden email]
> Subject: [xstream-user] Profiling XStream
>
> Hi,
>
>      My application has two possible startup states:
>
> - No configuration file is found, using the default settings and
> generate a new configuration file on shutdown
>
> - Configuration file is found, read objects using XStream's
> ObjectInputStream.readObject()
>
>      I have noticed that when a configuration file has to be loaded by
> XStream, it takes 1.7 seconds for a 70k file. An extra 1.7 seconds
> startup time is a major problem for my client-side application because
> it translates into an increase by 37% and is very noticable. And this is
> only with a relatively small configuration file, so I worry what happens
> as it grows.
>
>      I tried using JProfiler to track down what is bogging down the CPU
> but all I see is:
>
> ObjectInputStream.readObject():397 invoking
> CustomObjectInputStream.readObjectOverride() invoking
> XStream$2.readFromStream():66 invoking
> XStream.unmarshal():774 invoking
> XStream.unmarshal():500 invoking
> ReferenceByXPathMarshallingStrategy.unmarshal:521
> TreeUnmarshaller.start:12
> ReferenceByXPathMarshallingStrategy.convertAnother:99
> TreeUnmarshaller.convertAnother:39
> [... goes on and on ...]
>
>      At no point is any of my code being invoked as far as I can see (in
> the form of readResolve() etc). Is there any way for you guys to profile
> XStream to optimize it further or suggest ways for me optimize the
> configuration file loading process? Is this a normal loading time for 70k?
>
> Thank you,
> Gili

--
http://www.desktopbeautifier.com/