<div dir="ltr"><div>Hm I think currently the base behaviour is that<br> decompressed patch should not exist for the user.<br></div><div>Everything except pc_uncompress returns compressed patch.<br></div><div>is it a good idea? I don't know.<br></div><div>I would say that the user should not worry to think about using compressing function at all.<br></div><div><br>Dataset | subset size(Million pts) | compressing (Million pts/s) | decompressing (Million pts/s)<br>Lidar | 473.3 | 4,49 | 4,21<br></div><div>21 attributes | 105.7 | 1,11 | 2,62<br></div><div>Stereo | 70 | 2,44 | 7,38<br><br></div><div>I test decompression speed by measuring time(uncompress(compress(uncompress))) - time(compress(uncompress)) <br></div><div><br></div>Cheers<br></div><div class="gmail_extra"><br><div class="gmail_quote">2015-04-16 17:21 GMT+02:00 Sandro Santilli <span dir="ltr"><<a href="mailto:strk@keybit.net" target="_blank">strk@keybit.net</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wed, Apr 15, 2015 at 08:31:45PM +0200, Rémi Cura wrote:<br>
> From what I understand pgpointcloud is much faster to uncompress zip than<br>
> to compress it.<br>
> (roughly about 3 times)<br>
<br>
</span>That's supposedly the norm with deflate compression, to be faster<br>
at decompressing (and probably true for most other compression schemes).<br>
<br>
How do you test decompression speed ?<br>
<br>
I found my initial naive attempt of using PC_FilterEquals to be misleading<br>
as the result of PC_FilterEquals is again a patch, and the patch is<br>
compressed again using the schema-determined compression.<br>
<br>
This means that PC_FilterEquals( PC_Uncompress(p), ... ) returns a<br>
_compressed_ patch, incurring in both decompression and compression<br>
costs.<br>
<br>
I'm not sure this is a sane behavior.<br>
<br>
--strk;<br>
</blockquote></div><br></div>