<div dir="ltr">Well, I'm leaning on the tooling I have in OSX, which includes a sampling profiler in the Instruments.app that hides within the XCode bundle. Then I just get the pg_backend_pid() of the process I'm using to generate load and point it at that one process and put the load on it, generally for a minute or so to give the sampler ample time to find all the points of pain. For the Linux crew I'm not sure what the equivalent would be. Certainly compared to old skool things like gprof, a sampling profiler is massively better, in terms of ease of use and depth of analysis.<div><br>P</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 2, 2017 at 5:19 PM, Darafei "Komяpa" Praliaskouski <span dir="ltr"><<a href="mailto:me@komzpa.net" target="_blank">me@komzpa.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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" target="_blank">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><div class="h5"><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></div></div>
______________________________<wbr>_________________<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/<wbr>mailman/listinfo/postgis-devel</a></blockquote></div>
<br>______________________________<wbr>_________________<br>
postgis-devel mailing list<br>
<a href="mailto:postgis-devel@lists.osgeo.org">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/<wbr>mailman/listinfo/postgis-devel</a><br></blockquote></div><br></div>