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

[Even Rouault]

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

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com