[PROJ] Performance of proj_create_crs_to_crs()

[Kristian Evers]

Paul,

Sure, initialising PJ objects is a lot more expensive in PROJ 6 than
it has been previously. All the new fancy features come at a price. It
is to be expected. Before it was quite straight forward what would happen
when creating a PJ object but now we accept CRS description in a number
of different formats and do a lookup in the CRS database to find all the
possible transformations between your two CRS’s. Doing all that costs
CPU cycles. I am sure there’s a potential for optimisation but that has
not been the primary concern for this release.

Personally I don’t worry too much about the time it takes to instantiate
PJ objects since usually you would only have to do it once. I can see how
PostGIS might be different in that regard so your strategy of caching the
objects seems sound.

/Kristian


> On 17 Feb 2019, at 16:24, Paul Ramsey <pramsey at cleverelephant.ca> wrote:
> 
> So, having gotten all the axis swapping tap dancing working, I went to
> run some of my favourite transforms around BC, finishing up with one
> of my favourites...
> 
>  st_transform('SRID=3005;POINT(1000000 0)',4267)
> 
> This takes a point from a NAD83 projected system (EPSG:3005) to a
> NAD27 geodetic system (EPSG:4267).
> 
> Here's the crazy part: this transformation takes 400ms, and the time
> is all spend in in proj, getting the PJ.
> 
> I ran 20-30 of them in a row and captured the workload in Instruments
> in case these function calls ring any bells WRT overhead,
> 
> https://pasteboard.co/I1AXN5b.png
> 
> Fortunately for bulk conversion PostGIS already caches the projection
> object, in fact most of my work this week was in renovating that part
> of the code, but older versions of Proj are much much faster in
> resolving projections from projection strings.
> 
> Thoughts?
> _______________________________________________
> PROJ mailing list
> PROJ at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/proj