[pgpointcloud] RLE and SIGBITS heuristics

[Rémi Cura]

OUps

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

2015-04-16 17:29 GMT+02:00 Rémi Cura <remi.cura at gmail.com>:

> 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/925d9e1d/attachment.html>