Improve Replay Performance

[GoogleCodeExporter]

1) test XStream converters (said to be faster)
2) find a faster PNG encoding / decoding library

Original issue reported on code.google.com by r.biedert on 6 Sep 2010 at 3:40

[GoogleCodeExporter]

Owner changed.

Original comment by r.biedert on 7 Sep 2010 at 3:22

[GoogleCodeExporter]

@1: Run two benchmark-suites to verify any performance differences between 
writing the data with an ObjectOutputStream, xstream.toXML() and 
xstream+Converter

Results: xstream+converter are 2,3 to 2,9 times faster than using our 
ObjectOutputStreams.

But to be able to use the converters for reading, all event converters have to 
implement all get and set methods for their internal variables (e.g. 
EyeTrackingEventContainer has no set methods at all and missing get methods for 
the variables "validity" and "version").

@2: I compared the PNGEncoder http://objectplanet.com/pngencoder/ with the 
encoding from java ImageIO. 

Results: PNGEncoder is about twice as fast as ImageIO.

But I still vote for the usage of Jpeg instead of PNG for desktop/browser 
screenshots.
1. The Jpeg files are smaller (80% quality settings) and afaik the conversion 
is hardware accelerated (could be wrong).
2. The generated PNGs were sometimes bigger than the uncompressed *.tiff files 
regardless of the PNG encoder (Apple Preview, PNGEncoder, ImageIO)

Still have to look for a good PNG decoder and doing benchmarks...

Original comment by arman.va...@gmail.com on 12 Oct 2010 at 6:09

• Changed state: Started

[GoogleCodeExporter]

After implementing the missing getter/setters/constructors for 
EyeTrackingEventContainer.java I did another test.

Generating 1000000 sample data in 1.374s.

ObjectOutputStream benchmark without converter took 115.635s.
ObjectOutputStream benchmark with converter took 54.044s.
ObjectInputStream benchmark without converter took 99.019s.
ObjectInputStream benchmark with converter took 32.57s.

The benchmarks speak for themselves I think.

Original comment by arman.va...@gmail.com on 18 Oct 2010 at 12:32

[GoogleCodeExporter]

Do it so :-)

Original comment by r.biedert on 18 Oct 2010 at 4:34

[GoogleCodeExporter]

Do it so :-)

Original comment by r.biedert on 18 Oct 2010 at 4:34

[GoogleCodeExporter]

PNG codec is currently set on hold...

Included a converter for EyeTrackingEventContainer. Other converters might in 
the upcoming commitments.

Original comment by arman.va...@gmail.com on 27 Oct 2010 at 1:54

• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

ARRRRRRRRRR-man, check that converter can deal with NULL types for the various 
fields please *g*

Original comment by r.biedert on 21 Feb 2011 at 5:54

[GoogleCodeExporter]

E.g., like this:

  <EyeTrackingEventContainer>
    <originalEventTime>10513</originalEventTime>
    <combinedCenter>
      <x>556</x>
      <y>449</y>
    </combinedCenter>
    <leftEyeDistance>0.0</leftEyeDistance>
    <pupilSizeLeft>0.0</pupilSizeLeft>
    <pupilSizeRight>0.0</pupilSizeRight>
    <rightEyeDistance>0.0</rightEyeDistance>
    <validity>true</validity>
    <version>1</version>
  </EyeTrackingEventContainer>

Original comment by r.biedert on 21 Feb 2011 at 5:55

[GoogleCodeExporter]

Please choose: The bug occurs

[  ] while reading
[  ] while writing
[  ] doesn't matter.

;)

Original comment by arman.va...@gmail.com on 21 Feb 2011 at 6:08

[GoogleCodeExporter]

Please choose: The bug occurs

[x] while reading
[x] while writing
[  ] doesn't matter.

Actually I'm not sure if its (or should be considered as) a reading or writing 
bug, probably rather a reading bug. 

Original comment by r.biedert on 21 Feb 2011 at 7:11

[GoogleCodeExporter]

I've sent you a new version of the converter... It should check while reading 
whether the strings in the XML/XStream file are null and set some dummy values 
if necessary...

Original comment by arman.va...@gmail.com on 21 Feb 2011 at 7:15