[Liblas-devel] RE: I/O performance? -- your help requested!

[Michael P. Gerlek]

And the answer is:

  The C++ I/O runs were anywhere from 0% to 40% slower.
  The average slowdown is about 15%, and in no case was C++ ever faster than
C.
  Choice of platform (windows/linux) doesn't seem a factor.

Now, you might point out that in the case of this particular benchmark the
C++ code was written suboptimally.  Fair enough, but I'd counter that this
still matters to us, since we have an existence proof that some of us here
developers will, in fact, unknowingly and innocently do the Wrong Thing.

Thanks to those who gave me data!  There will be more on this topic in the
weeks and months to come...

-mpg


> -----Original Message-----
> From: Michael P. Gerlek [mailto:mpg at flaxen.com]
> Sent: Friday, February 04, 2011 8:39 AM
> To: liblas-devel at lists.osgeo.org
> Subject: I/O performance? -- your help requested!
> 
> Do you have 5-10 minutes to spare today?
> 
> Your libLAS team (well, me anyway) is wondering about I/O performance of
> the liblas kit -- specifically, when doing binary reading and writing, is
there
> any fundamental performance difference between using C-style FILE* I/O
> and
> C++-style stream I/O?  And if streams are better, would boost's stream
> C++be
> better still?  If you google around a bit, you'll find lots of
contradictory (and
> sometimes overly passionate) statements about this topic.  At the end of
the
> day, though, the consensus seems to be that:
> 
>   (1) you need to be "smart" if you're using C++ I/O -- it is easy to
shoot
> yourself in the foot
>   (2) modern C++ streams are implemented on top of the native OS APIs
>   (3) under Visual Studio, FILE* operations and streams are both
> implemented using the win32 APIs, but streams have an additional lock
(that
> is claimed by some to be not needed)
> 
> and, most importantly,
> 
>   (4) performance varies greatly with different I/O patterns, e.g. large
> sequential block reads vs small random reads
> 
> Very fortunately, we happen to already have a rough, 1st-order I/O
> performance test built into the laszip tree.  If you have that tree built
> (http://hg.liblas.org/zip), in Release mode, could you please send me the
> results of running the "laszippertest" test app, as follows?
> 
>     time ./laszippertest -n 1000000
>     time ./laszippertest -n 1000000
>     time ./laszippertest -n 1000000
>     time ./laszippertest -n 1000000 -s
>     time ./laszippertest -n 1000000 -s
>     time ./laszippertest -n 1000000 -s
> 
> The first three runs will encode and decode 1 million random points using
> FILEs, and the second three will do it with streams.  This is not a
perfect test,
> but it represents something approximating the real I/O footprint or traces
> that liblas uses.
> 
> Oh, and be sure to include the kind of platform (processor speed,
compiler,
> OS) you're running it on.
> 
> Thanks much!
> 
> -mpg
>