[postgis-devel] Transform() PROJ4 cache patch
'strk'
strk at keybit.net
Fri Nov 4 03:32:27 PST 2005
Thanks for timing Mark.
It seems there's no much to gain from invoking transform_geometry
directly in terms of performance.
Still, I'd keep it as users might want to perform reprojection
even w/out a spatial_ref_sys table.
There's no work involved in keeping it, so what's the point of
removing it ?
--strk;
On Fri, Nov 04, 2005 at 11:24:42AM -0000, Mark Cave-Ayland wrote:
>
> > -----Original Message-----
> > From: 'strk' [mailto:strk at keybit.net]
> > Sent: 04 November 2005 09:43
> > To: Mark Cave-Ayland (External)
> > Subject: Re: [postgis-devel] Transform() PROJ4 cache patch
>
> (cut)
>
> > CASE:
> > - transformation applied to a single geometry
> > - argument SRID projections are not in the cache
> > Which is faster ?
> >
> > --strk;
>
>
> Hi strk,
>
> Here are some results from testing here on different numbers of points (1,
> 5, 10, 100, 1000, 10000, 100000):
>
>
> CONSTANT TRANSFORMATIONS (i.e. not on a column):
>
> transform_geometry() ~ 0.5ms faster than transform_cache() for all cases
>
>
> COLUMN TRANSFORMATIONS
>
> infomapper_dev=# select count(*) FROM (SELECT transform_geometry(geom,
> '+proj=tmerc +lat_0=49 +lon_0=-2 +k=0.999601 +x_0=400000 +y_0=-100000
> +ellps=airy +units=m +no_defs'::text, '+proj=longlat +ellps=WGS84
> +datum=WGS84 +no_defs'::text, 4326) FROM osgb_point LIMIT 1) AS foo;
> count
> -------
> 1
> (1 row)
>
> Time: 0.978 ms
> infomapper_dev=# select count(*) FROM (SELECT transform_cache(geom, 4326)
> FROM osgb_point LIMIT 1) AS foo; count
> -------
> 1
> (1 row)
>
> Time: 1.459 ms
>
>
> infomapper_dev=# select count(*) FROM (SELECT transform_geometry(geom,
> '+proj=tmerc +lat_0=49 +lon_0=-2 +k=0.999601 +x_0=400000 +y_0=-100000
> +ellps=airy +units=m +no_defs'::text, '+proj=longlat +ellps=WGS84
> +datum=WGS84 +no_defs'::text, 4326) FROM osgb_point LIMIT 5) AS foo;
> count
> -------
> 5
> (1 row)
>
> Time: 1.298 ms
> infomapper_dev=# select count(*) FROM (SELECT transform_cache(geom, 4326)
> FROM osgb_point LIMIT 5) AS foo; count
> -------
> 5
> (1 row)
>
> Time: 1.565 ms
>
>
> infomapper_dev=# select count(*) FROM (SELECT transform_geometry(geom,
> '+proj=tmerc +lat_0=49 +lon_0=-2 +k=0.999601 +x_0=400000 +y_0=-100000
> +ellps=airy +units=m +no_defs'::text, '+proj=longlat +ellps=WGS84
> +datum=WGS84 +no_defs'::text, 4326) FROM osgb_point LIMIT 10) AS foo;
> count
> -------
> 10
> (1 row)
>
> Time: 1.680 ms
> infomapper_dev=# select count(*) FROM (SELECT transform_cache(geom, 4326)
> FROM osgb_point LIMIT 10) AS foo; count
> -------
> 10
> (1 row)
>
> Time: 1.583 ms
>
>
> infomapper_dev=# select count(*) FROM (SELECT transform_geometry(geom,
> '+proj=tmerc +lat_0=49 +lon_0=-2 +k=0.999601 +x_0=400000 +y_0=-100000
> +ellps=airy +units=m +no_defs'::text, '+proj=longlat +ellps=WGS84
> +datum=WGS84 +no_defs'::text, 4326) FROM osgb_point LIMIT 100) AS foo;
> count
> -------
> 100
> (1 row)
>
> Time: 8.428 ms
> infomapper_dev=# select count(*) FROM (SELECT transform_cache(geom, 4326)
> FROM osgb_point LIMIT 100) AS foo; count
> -------
> 100
> (1 row)
>
> Time: 3.094 ms
>
>
> infomapper_dev=# select count(*) FROM (SELECT transform_geometry(geom,
> '+proj=tmerc +lat_0=49 +lon_0=-2 +k=0.999601 +x_0=400000 +y_0=-100000
> +ellps=airy +units=m +no_defs'::text, '+proj=longlat +ellps=WGS84
> +datum=WGS84 +no_defs'::text, 4326) FROM osgb_point LIMIT 1000) AS foo;
> count
> -------
> 1000
> (1 row)
>
> Time: 76.267 ms
> infomapper_dev=# select count(*) FROM (SELECT transform_cache(geom, 4326)
> FROM osgb_point LIMIT 1000) AS foo; count
> -------
> 1000
> (1 row)
>
> Time: 17.709 ms
>
>
> infomapper_dev=# select count(*) FROM (SELECT transform_geometry(geom,
> '+proj=tmerc +lat_0=49 +lon_0=-2 +k=0.999601 +x_0=400000 +y_0=-100000
> +ellps=airy +units=m +no_defs'::text, '+proj=longlat +ellps=WGS84
> +datum=WGS84 +no_defs'::text, 4326) FROM osgb_point LIMIT 10000) AS foo;
> count
> -------
> 10000
> (1 row)
>
> Time: 753.626 ms
> infomapper_dev=# select count(*) FROM (SELECT transform_cache(geom, 4326)
> FROM osgb_point LIMIT 10000) AS foo; count
> -------
> 10000
> (1 row)
>
> Time: 164.406 ms
>
>
> infomapper_dev=# select count(*) FROM (SELECT transform_geometry(geom,
> '+proj=tmerc +lat_0=49 +lon_0=-2 +k=0.999601 +x_0=400000 +y_0=-100000
> +ellps=airy +units=m +no_defs'::text, '+proj=longlat +ellps=WGS84
> +datum=WGS84 +no_defs'::text, 4326) FROM osgb_point LIMIT 100000) AS foo;
> count
> --------
> 100000
> (1 row)
>
> Time: 7532.049 ms
> infomapper_dev=# select count(*) FROM (SELECT transform_cache(geom, 4326)
> FROM osgb_point LIMIT 100000) AS foo; count
> --------
> 100000
> (1 row)
>
> Time: 1640.356 ms
>
>
> So it looks like the break even point is somewhere between 5 and 10 points
> to make a saving. Since it is only in the region of 0.5ms for such a small
> number of points, IMHO, I can't see the point of maintaining two separate
> code paths.
>
> I'm also more confident about that patch as it's been running on our dev
> server for a week now without any problems, plus I see that they do a
> similar thing for caching connections in contrib/dblink but using a
> longer-term context.
>
> BTW shouldn't we move this back onto postgis-devel?
>
>
> Kind regards,
>
> Mark.
>
> ------------------------
> WebBased Ltd
> 17 Research Way
> Plymouth
> PL6 8BT
>
> T: +44 (0)1752 797131
> F: +44 (0)1752 791023
>
> http://www.webbased.co.uk
> http://www.infomapper.com
> http://www.swtc.co.uk
>
> This email and any attachments are confidential to the intended recipient
> and may also be privileged. If you are not the intended recipient please
> delete it from your system and notify the sender. You should not copy it or
> use it for any purpose nor disclose or distribute its contents to any other
> person.
>
More information about the postgis-devel
mailing list