[mapserver-dev] fastpath 4326->3857 reprojections

[Frank Warmerdam]

On 12-02-11 01:37 AM, thomas bonfort wrote:
> Hi all,
>
> During the codesprint I talked to Daniel about a possible speedup
> patch we could use to bypass going through proj when performing the
> common 4326 to 3857 (google mercator) reprojections. During my trip
> back from the codesprint I implemented a quick patch that does this,
> and I think that the benefits are sufficiently important under this
> (rather common) test case to merit being pushed to trunk.
>
> test-case:
>   - using the mapserver-utils osm mapfile, we seed the first 6 zoom
> levels of the google-mercator grid. Depending on the zoom level, this
> mapfile has two (land and borders) or one (borders) layers that need
> to go through reprojection. There are between 1 and 4 other layers
> that are already in 3857 and therefore do not need reprojecting.
>   - the seeding is done with the mapcache seeding tool, which can be
> configured to use multiple threads to do parallel rendering. The
> seeding is done by directly using the libmapserver api (i.e. direct
> calls to msDrawMap, not going through curl http getmap requests).
>   - bug 4041 (http://trac.osgeo.org/mapserver/ticket/4041) contains a
> patch to avoid locking inside mapserver around proj calls, for trunk
> versions of proj. In the following result spreadsheet "with/without
> 480" refers to the fact that this patch is applied or not (480 stands
> for version 4.8.0 of proj)
>
> without further ado, here's the resulting spreadsheet, which gives the
> time in seconds needed to entirely seed the first 6 zoom levels:
>
> https://docs.google.com/spreadsheet/pub?key=0AnCiCdIXpTHidHJ0YzVmSW54WncwZ2lGSS1wQ2xNZHc&output=html
>
> tl;dr
>
> - if we factor out thread locking (which concerns the cgi/fastcgi
> performance), the speedup is x 2.5
> - in the multithreaded seeding case, the speedup is x 37

Thomas,

Excellent investigation.  I'd appreciate it if you could prepare a more
modest complexity demonstration of this.  I'd like to better understand
why the general time via PROJ.4 is so bad.  In vector reprojection and
rendering cases i've looked into in the past the time spent in PROJ was
quite modest.

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://home.gdal.org/warmerda
and watch the world go round - Rush    | Geospatial Software Developer