[pgpointcloud] Wrong serialized size of a PcPoint ?

[Rémi Cura]

Wow,
I wonder how you got the idea to do this check!
ending with 19 bytes may have very bad consequences for perf if it is not a
8 byte multiple.
Nice find.

Cheers,
Rémi-C

2015-04-08 11:56 GMT+02:00 Sandro Santilli <strk at keybit.net>:

> Checking the size of PcPoint values (with pc_memsize and pg_column_size)
> I found that we're using 11 bytes for the header when instead only 8 are
> required:
>
>  typedef struct
>  {
>    uint32_t size; //   4
>    uint32_t pcid; //  +4 = 8
>    uint8_t data[1];
>  }
>  SERIALIZED_POINT;
>
> This is because the code uses sizeof(SERIALIZED_POINT) - 1 to determine
> the required size, but sizeof(SERIALIZED_POINT) is 12 on my machine,
> rather than 9 as expected by the code.
>
> In turn, 12 means that the structure is padded to the closest 4bytes
> boundary (4+4+4 rather than 4+4+1).
>
> As we're going to add the actual size of the dimensions, that padding
> would not necessarely be needed. For example, a PcPoint with 3 4bytes
> dimensions would be perfectly aligned with just 16 bytes. Instead
> it uses 8+11=19 bytes.
>
> Similar assumption (no padding) is done for the PcPatch case, whose
> struct also ends with an uint8_t.
>
> I hadn't checked if such 3 bytes padding sums up for each point in
> a patch but it sounds like something worth inspecting.
>
> --strk;
>
>   ()   Free GIS & Flash consultant/developer
>   /\   http://strk.keybit.net/services.html
> _______________________________________________
> pgpointcloud mailing list
> pgpointcloud at lists.osgeo.org
> http://lists.osgeo.org/cgi-bin/mailman/listinfo/pgpointcloud
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/pgpointcloud/attachments/20150408/f1669a40/attachment.html>