View Issue Details [ Jump to Notes ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0010274ParaViewBugpublic2010-02-10 15:552016-08-12 09:57
ReporterUtkarsh Ayachit 
Assigned ToKitware Robot 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionmoved 
PlatformOSOS Version
Product Version 
Target VersionSomedayFixed in Version 
Summary0010274: zlib compression in vtkMPIMoveData is slowing client-server rendering
Descriptionzlib compression in vtkMPIMoveData is slowing down data delivery considerably. Following is a timer log for can.ex2. Possible solution would be to compress only when data size is beyond a threshold.

===client====
Still Render, 1.21436 seconds
    Execute vtkMPIMoveData id: 674, 1.19688 seconds
        Zlib uncompress, 0.016727 seconds

===server====
Execute vtkMPIMoveData id: 674, 1.1723 seconds
    Dataserver sending to client, 1.17105 seconds
        Zlib compress, 1.16047 seconds
TagsNo tags attached.
Project
Topic Name
Type
Attached Filespdf file icon geometry_compression.pdf [^] (205,911 bytes) 2010-02-15 16:07

 Relationships
related to 0009409closedUtkarsh Ayachit Use zlib compression when transferring geometry to client 

  Notes
(0019533)
Burlen (developer)
2010-02-15 16:07
edited on: 2010-02-15 16:53

 Just to clarify: The investigations (https://www.vtk.org/Bug/file/7866/geometry_compression.pdf [^]) showed at most a 2x speed up, and only for very large data and slower networks. If you are going to implement it then there are a couple of things to keep in mind:

1) geometry compression hurts performance on fast networks
2) only makes much of a difference (and at most 2x speedup) on slower networks for very large data
3) for binary floating point data, zlib compression level affects run time drastically, but higher levels don't increase the compression ratio.

I noticed that in vtkMPIMoveData the compression level is set by the compile time variable Z_DEFAULT_COMPRESSION, which is typically 6, that will kill any hopes of a speedup. You should always use zlib compression level of 1 on the binary floating point data.

Also, if you're going to compress geometry or other binary floating point data during communication you might look at LZO, it's suposed to be faster than zlib.
http://www.oberhumer.com/opensource/lzo/ [^]
I didn't do any benchmarks with LZO.

summary of benchmarks. On this data compression ratios are consistently between 1.5 and 2. localhost connection saw a slow down across the board. The 100MB network saw a speedup between 1.4 and 1.7 across the board. The broadband network saw a speed up which gradually approached 2 starting as geometry size increased passed 10kB. For both slower networks speedup increases with geometry size up to about 10MB where a plateau seems to be reached.
(0037786)
Kitware Robot (administrator)
2016-08-12 09:57

 Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current ParaView Issues page linked in the banner at the top of this page.

 Issue History
Date Modified Username Field Change
2010-02-10 15:55 Utkarsh Ayachit New Issue
2010-02-10 15:56 Utkarsh Ayachit Relationship added related to 0009409
2010-02-10 15:56 Utkarsh Ayachit Description Updated
2010-02-15 16:07 Burlen Note Added: 0019533
2010-02-15 16:07 Burlen File Added: geometry_compression.pdf
2010-02-15 16:11 Burlen Note Edited: 0019533
2010-02-15 16:40 Burlen Note Edited: 0019533
2010-02-15 16:46 Burlen Note Edited: 0019533
2010-02-15 16:53 Burlen Note Edited: 0019533
2010-04-16 01:37 Utkarsh Ayachit Priority immediate => normal
2010-04-16 01:37 Utkarsh Ayachit Target Version 3.8 => Someday
2016-08-12 09:57 Kitware Robot Note Added: 0037786
2016-08-12 09:57 Kitware Robot Status expired => closed
2016-08-12 09:57 Kitware Robot Resolution open => moved
2016-08-12 09:57 Kitware Robot Assigned To => Kitware Robot

Copyright © 2000 - 2018 MantisBT Team