<div dir="ltr">Hello,<div><br></div><div>Can you please share the way you are using profiler on postgis?<br>I'd like to profile sorting by geometry. For now I've found for myself <br><br><div>objdump -S --disassemble /usr/lib/liblwgeom-2.5.so.0 |less</div></div><div><br>... but that doesn't scale well enough. Still allows to see that geometry/geography if's reading bits of header with something hidden three files away under #define aren't a simple thing.<br><br>For _in_place suggestion, I think it's enough to make sure it's done for the critical path of MVT and codified somewhere as a guideline.<br></div></div><br><div class="gmail_quote"><div dir="ltr">вт, 3 окт. 2017 г. в 0:53, Paul Ramsey <<a href="mailto:pramsey@cleverelephant.ca">pramsey@cleverelephant.ca</a>>:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hey devs,<div>So, in pursuit of spare CPU cycles for the good folks at Carto, I've been putting various workloads through a profiler. Some of the results you've seen in recent tweaks committed.</div><div><br></div><div>One thing I found as a general rule was that as the number of simple objects goes up, the more noticeable the overhead of things like memory allocation / deallocation becomes. So the overhead of just constructing an LWPOINT on a point, when you're slamming through 1M of them, is not nothing.</div><div><br></div><div>For some workloads, like generating MVT (there it is) we call numerous geometry processing functions in a row. For some functions, that expect const LWGEOM inputs, that can result in a lot of cloning of objects, and hence, memory management. For other functions, that expect to modify things in place, the coordinates are just altered right there.</div><div><br></div><div>This has always been a little ugliness in our API, and for a while we settled on defaulting to making copies, so the API was at least getting cleaner. But also getting slower.</div><div><br></div><div>I built a prototype for generating MVT that does all the coordinate processing in place, and for bulk simple objects it ran about 30% faster than the existing code. There's a benefit to be had to in working in place.<br></div><div><br></div><div>I propose that we... cut the baby in half.</div><div><br></div><div>* All liblwgeom functions that do in place coordinate modification should be re-named to *_in_place() and a bare version that takes a const LWGEOM and returns a copy as necessary be added.</div><div>* All liblwgeom functions that already take const LWGEOM be supplemented with *_in_place() variants so that it's possible to build processing chains that are capable of doing processing with a minimal allocation/deallocation footprint.<br></div><div><br></div><div>Functions on my list immediately:</div><div><br></div><div><div>  * remove_repeated_points</div><div>  * simplify</div><div>  * affine</div><div>  * grid</div><div>  * transform</div><div>  </div></div><div>I will, however, do a full review and attempt to ensure all non-GEOS functions have in_place variants available in liblwgeom.</div><div><br></div><div>Thoughts?</div><div><br></div><div>P.</div><div><br></div><div><br></div></div>
_______________________________________________<br>
postgis-devel mailing list<br>
<a href="mailto:postgis-devel@lists.osgeo.org" target="_blank">postgis-devel@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/postgis-devel" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/postgis-devel</a></blockquote></div>