[PROJ] Performance of proj_create_crs_to_crs()

[Paul Ramsey]

Even,
Thanks so much, I can confirm that your PR makes my test run
(literally) 100x faster. (Takes about 1.5ms now)
Wonderful, wonderful!
P.

On Sun, Feb 17, 2019 at 10:46 AM Even Rouault
<even.rouault at spatialys.com> wrote:
>
> Paul,
>
> This is a very interesting use case, and one that has probably the worse
> runtime.
>
> On my system, the following runs in 16.9 s, so 170 ms per instanciation
>
>         for(int i = 0; i < 100; i++)
>         {
>             PJ *pj = proj_create_crs_to_crs(NULL, "EPSG:3005", "EPSG:4267",
> NULL);
>             proj_destroy(pj);
>         }
>
> so not as dramatic as 400 ms.
>
> The reason is that the NAD27 <-> NAD83 conversion has several dozains of
> potential paths (one per US state), and PROJ explore them. But, after
> analysis, the main reason for the slowness was that it also tried by default
> to find an intermediate CRS to explore better alternate transformation paths,
> and WGS84 was a very prolific one in that case. But actually going through
> WGS84 doesn't really give better pipelines at the end.
>
> I've just issued PR https://github.com/OSGeo/proj.4/pull/1276 which disables
> by default research of intermediate CRS when there is at least a direct
> transformation. This should be good enough for most use cases. With this
> change, in your use case, the above loop runs in 1.56 s, so 16 ms per
> instanciation.
>
> Even
>
> > 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, screenshot
> > attached.
> >
> > 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?
> >
> > P.
>
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com