[pgpointcloud] RLE and SIGBITS heuristics

[Rémi Cura]

Hm I think currently the base behaviour is that
 decompressed patch should not exist for the user.
Everything except pc_uncompress returns compressed patch.
is it a good idea? I don't know.
I would say that the user should not worry to think about using compressing
function at all.

Dataset        |  subset size(Million pts) | compressing (Million pts/s) |
decompressing (Million pts/s)
Lidar           |            473.3                |               4,49
              |             4,21
21 attributes |           105.7                 |
1,11                     |             2,62
Stereo         |              70                  |                2,44
               |             7,38

I test decompression speed by measuring
time(uncompress(compress(uncompress))) - time(compress(uncompress))

Cheers

2015-04-16 17:21 GMT+02:00 Sandro Santilli <strk at keybit.net>:

> On Wed, Apr 15, 2015 at 08:31:45PM +0200, Rémi Cura wrote:
> > From what I understand pgpointcloud is much faster to uncompress zip than
> > to compress it.
> > (roughly about 3 times)
>
> That's supposedly the norm with deflate compression, to be faster
> at decompressing (and probably true for most other compression schemes).
>
> How do you test decompression speed ?
>
> I found my initial naive attempt of using PC_FilterEquals to be misleading
> as the result of PC_FilterEquals is again a patch, and the patch is
> compressed again using the schema-determined compression.
>
> This means that PC_FilterEquals( PC_Uncompress(p), ... ) returns a
> _compressed_ patch, incurring in both decompression and compression
> costs.
>
> I'm not sure this is a sane behavior.
>
> --strk;
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/pgpointcloud/attachments/20150416/cbbb3ec5/attachment.html>