[mapserver-dev] EPSG File Overhead

[Paul Ramsey]

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/
>>
>>
>