[mapserver-dev] EPSG File Overhead

Stephen Woodbridge woodbri at swoodbridge.com
Wed Feb 4 23:08:10 EST 2009


Paul,

I do not understand why we don't just compile the project files into a 
binary form that does not require parsing and is indexed/hashed for fast 
lookups. It doesn't mean that we can't also use the text versions of the 
files. A simple MS utility to compile/dump the binary version that would 
solve the problem and keep it pretty simple and light weight.

-Steve W

Paul Ramsey wrote:
> It wouldn't be that hard to add something to the construction of the
> projectionObj that hashes all the configuration arguments into one key
> for identity comparison... frankly, the overhead in ESPG searching is
> so much higher (you pay it for every layer, every parse run, even if
> you don't use the layer) than the overhead for reprojection, you're
> still better off with the explicit strings.
> 
> P.
> 
> On Wed, Feb 4, 2009 at 1:47 PM, Paul Ramsey <pramsey at opengeo.org> wrote:
>> Yes, it's a pretty blunt test:
>>
>> http://trac.osgeo.org/mapserver/browser/trunk/mapserver/mapproject.c#L67
>>
>> On Wed, Feb 4, 2009 at 1:08 PM, Paul Spencer <pspencer at dmsolutions.ca> wrote:
>>> I would like to note that changing mapfile projection blocks from init= to
>>> the equivalent proj strings does cause problems with WMS services as every
>>> feature is reprojected (even though the two projections are identical).
>>>
>>> Paul
>>>
>>> On 4-Feb-09, at 3:56 PM, Paul Ramsey wrote:
>>>
>>>> I'm firing up Andrea's suite and getting some profiling results...
>>>>
>>>> Using the tiger_pg test harness, and his default map file, with the
>>>> EPSG codes at the top of the EPSG file, I get throughput of 35.5 req/s
>>>> and profiling shows fscanf taking 26% of time. Editing the map file to
>>>> replace init=epsg: entries with full proj4 definitions, and running
>>>> again, I get throughput of 44.7 req/s and profiling shows that proj4
>>>> overhead has dropped to invisible (probably because there are no
>>>> actual reprojections in this test). At that point, the biggest CPU
>>>> overhead is compressing the output GIF, so we're going very well
>>>> indeed.
>>>> _______________________________________________
>>>> mapserver-dev mailing list
>>>> mapserver-dev at lists.osgeo.org
>>>> http://lists.osgeo.org/mailman/listinfo/mapserver-dev
>>>
>>> __________________________________________
>>>
>>>   Paul Spencer
>>>   Chief Technology Officer
>>>   DM Solutions Group Inc
>>>   http://research.dmsolutions.ca/
>>>
>>>
> _______________________________________________
> mapserver-dev mailing list
> mapserver-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapserver-dev



More information about the mapserver-dev mailing list