[mapserver-dev] RFC 126: Port to PROJ 6 API

[Daniel Morissette]

Hi Even,

FWIW I just ran the "time mapserv >/dev/null" test on one of my servers 
and I get "0.018s" (18ms) for a single call... and a loop of 100 calls 
gives 1.84s, so the process invocation is fairly stable at 18ms in my 
case. Of course for a really meaningful comparison we'd have to run the 
full PROJ4 vs PROJ6 tests on the same machine, but that's not a priority 
for me for now.

I also agree that FastCGI is an option in many cases, and if the CGI 
performance really becomes an issue then we can consider other 
performance optimizations in a later phase of work.

Thanks

Daniel


On 2019-10-02 06:09, Even Rouault wrote:
> Hi Daniel,
> 
>>
>> The significant performance hit caught my attention for the CGI case
>> which is a more common use case than the RFC seems to suggest.
> 
> I would strongly suggest using FastCGI then. By using pure CGI, you'll
> definitely have to pay for the price of starting a new process, which is non
> neglectable.
> On my machine, "time mapserv >/dev/null" is 177 ms in the best case... I'd say
> that before trying to kill an extra 10ms, going after those 177ms should be
> the priority.
> 
>> Is there
>> really not much that can be done about that?  Is it really just the
>> projection setup that is slower or are the coordinate conversions also
>> slower?
> 
>  From the reports of PROJ users (see https://github.com/OSGeo/PROJ/issues/1367
> ), I think that projection setup is the main factor (and in my little bench,
> there are very few points to transform, so a potential extra cost for each
> coordinate conversion would't show up)
> 
>> Could we serialize the projection context pool for any given
>> mapfile to some kind of cache file in /tmp/ for instance and start from
>> the cached version at loadMap() time?  Could we get some gains this way
>> by not having to recompute all the projection transformations all the time?
> 
> I don't think that can be done on Mapserver side, at least not easily. For
> example proj_create_crs_to_crs() can create an object that is a collection of
> several potential coordinate transformations (depending on the area of use),
> and proj_trans() will select the one that is appropriate. This is opaque to
> the user.
> You could access to those different candidates by using the lower level API,
> proj_create_operations(), and then you can access the PROJ pipeline string and
> serialize it, but then you have to implement the logic to select the one that
> is appropriate given your input coordinate.
> Your suggestion might work, but that's a non trivial effort and code
> complication (handling the cache file could be tricky as well, to avoid 2
> concurrent processes overwriting it at the same time, etc).
> Wondering if that might not be done by PROJ itself (but not so obvious, since
> there is also a price to create a PROJ CRS object from a EPSG code, which
> requires lookups in the database)
> 
> I'd say that considering such optimizations would be for a phase 2, and the
> ratio effort/benefit is quite uncertain.
> 
> Even
> 


-- 
Daniel Morissette
Mapgears Inc
T: +1 418-696-5056 #201