[mapserver-dev] fastpath 4326->3857 reprojections

[thomas bonfort]

I'd be +0 on this: a speedup of this nature would be a nice incentive
for users to update their mapfiles and services to use 3857 instead of
the unofficial 900913 (the co-existence of these 2 identical codes has
the consequence of forcing going through a useless reprojection when
e.g. the layers are defined as 3857 but the request is in 900913).
That said supporting both 900913 and 3857 in the fastpath would be
trivial and wouldn't incur an additional cost performance wise.

regards,
thomas

On Sat, Feb 11, 2012 at 16:02, Stephen Woodbridge
<woodbri at swoodbridge.com> wrote:
> Wow! impressive results. While I know 3857 is the official code it would be
> nice if the patch also recognized 900913 as an alias for 3857, because it
> has been in common use for a few years.
>
> Thanks,
>  -Steve W
>
>
> On 2/11/2012 4: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
>> _______________________________________________
>> mapserver-dev mailing list
>> mapserver-dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/mapserver-dev
>
>
> _______________________________________________
> mapserver-dev mailing list
> mapserver-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapserver-dev