<div dir="ltr"><div>hello Markus and Vaclav,</div><div><br></div><div>thank you for your feedback. My answer is inline.</div><div><br></div><div><div dir="ltr" class="gmail_attr">On Wed, May 1, 2019 at 6:03 PM Markus Metz <<a href="mailto:markus.metz.giswork@gmail.com" target="_blank">markus.metz.giswork@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>IMHO the overhead of calling GRASS modules is insignificant because it is in the range of milliseconds. I am much more concerned whether executing a GRASS module takes days or hours or minutes.<br></div></div></blockquote><br class="gmail-Apple-interchange-newline"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">And the overhead is insignificant (not measurable) compared to actual execution time for larger datasets/regions. </blockquote><div><br></div><div>I would argue that this depends on what you are doing. For a single GRASS Session using a really big computational region the overhead is obviously negligible; I wrote that in the <a href="https://gist.github.com/pmav99/8f4546fe15940b3cb7db0cfb65e18d33#is-this-truly-a-problem">initial post</a> too. But if you do need to massively parallelize GRASS, then the overhead of setting up the GRASS Session and/or calling GRASS modules might be measurable too.</div><div><br>Regardless, the overhead</div><div><ul><li>can be noticeable while doing exploratory analysis </li><li>can be significant while *<i>developing</i>* GRASS (e.g. when running tests).</li></ul></div><div>BTW, let us also keep in mind that the majority of the tests should be using really small maps/computational regions (note: they currently don't, but that's a different issue) which means that the impact of this overhead should be larger </div><div> </div></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 2, 2019 at 4:49 AM Vaclav Petras <<a href="mailto:wenzeslaus@gmail.com" target="_blank">wenzeslaus@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Hi Panos and Markus,</div><div><br></div><div>I actually touched on this in my master's thesis [1, p. 54-58], specifically on the subprocess call overhead (i.e. not import or initialization overheads). I compared speed of calling subprocess in Python to a Python function call. The reason was that I was calling GRASS modules many times for small portions of my computational region, i.e. I was changing region always to the area/object of interest within the actual (user set) computational region. So, the overall process involved actually many subprocess calls depending on the size of data. Unfortunately, I don't have there a comparison of how the two cases (functions versus subprocesses) would look like in terms of time spend for the whole process.<br></div></div></div></div></blockquote><div><br></div><div>Again I would argue that the answer depends on what you are doing. Pansharpening a 100 pixel map, has a (comparatively) huge overhead. Pansharpening a landast tile, not so much. Regardless of that, I think we can all agree that directly calling a function implementing algorithm Foo is always going to be faster than calling a script that calls the same function. Unfortunately, and as you pointed out, perhaps most of the GRASS functionality is only accessible from the CLI and not through an API.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div></div><div><br></div>And speaking more generally, it seems to me that the functionality-CLI coupling issue is what might me be partially fueling Facundo's GSoC proposal (Python package for topology tools). There access to functionality does not seem direct enough to the user-programmer with overhead of subprocess call as well as related I/O cost, whether real or perceived, playing a role.<br></div></div></div></blockquote><div><br></div><div>I can't speak about Facundo. Nevertheless, whenever I try to work with the API, I do find it limited and it feels that it still has rough edges (e.g. <a href="https://trac.osgeo.org/grass/ticket/3833">#3833</a> and <a href="https://trac.osgeo.org/grass/ticket/3845">#3845</a> ). It very soon becomes clear that in order to get work done you need to use the Command Line Interface. As a programmer, I do find this annoying :P</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><br></div><div>Best,<br></div><div>Vaclav<br></div><div dir="ltr"><br></div><div dir="ltr">[1] Petras V. 2013. Building detection from aerial images in GRASS GIS environment. Master’s thesis. Czech Technical University in Prague. <a href="http://geo.fsv.cvut.cz/proj/dp/2013/vaclav-petras-dp-2013.pdf" target="_blank">http://geo.fsv.cvut.cz/proj/dp/2013/vaclav-petras-dp-2013.pdf</a></div></div></div></div></blockquote><div><br></div><div>Thank you for the link)<br><br>all the best,<br>Panos </div></div></div>