[mapserver-dev] [performance] mapserver list expressions

[thomas bonfort]

RFC passed and committed, docs updated.


On 5 April 2013 15:26, Stephen Woodbridge <woodbri at swoodbridge.com> wrote:

>  +1 on this change, just catching up on email. :)
>
> -Steve W
>
>
> On 4/4/2013 12:39 PM, thomas bonfort wrote:
>
> Daniel,
>
>  done:
> https://github.com/mapserver/docs/blob/branch-6-2/en/development/rfc/ms-rfc-95.txt
> (will appear on the website shortly)
>
>  I don't think it's worth calling for a new vote on the actual RFC, this
> email thread should suffice.
>
>  regards,
> thomas
>
>
>
> On 4 April 2013 16:18, Daniel Morissette <dmorissette at mapgears.com> wrote:
>
>> +1 on the addition.
>>
>> Bonus points if we could get a simple RFC to document and keep a trace of
>> the addition. The contents of this email with a tiny bit of editing might
>> be enough, it's just that having it in a RFC would be easier than looking
>> for it in a ticket or the list archives, and would allow us to refer to
>> this RFC as a one of the new features at release time.
>>
>> My 0.02$
>>
>> Daniel
>>
>>
>>
>> On 13-04-03 11:16 AM, thomas bonfort wrote:
>>
>>>  While profiling the openstreetmap renderings, I found a relatively low
>>> hanging performance speedup related to expressions when doing class
>>> filtering. The context relates to when you'd need to apply a given CLASS
>>> to multiple attribute values.
>>> Currently, to apply a single class to multiple values of an attribute,
>>> you can either use regular expressions, or use the IN operator, like
>>> this:
>>>
>>> LAYER
>>>    ...
>>>    CLASSITEM "type"
>>>    CLASS
>>>      EXPRESSION /primary|secondary|tertiary/  #regular expression on
>>> CLASSITEM
>>>      EXPRESSION ("[type]" IN "primary,secondary,tertiary") #"complex"
>>> parser expression
>>>      ...
>>>    END
>>> END
>>>
>>> Both methods require quite a bit of overhead, either in the regex system
>>> calls, or by using quite a few mallocs when going through the IN parser
>>> operation.
>>>
>>> We can cut down on this overhead by adding a "list" expression type,
>>> denoted by the { } delimiters, where the previous layer definition
>>> becomes:
>>>
>>>   LAYER
>>>    ...
>>>    CLASSITEM "type"
>>>    CLASS
>>>      EXPRESSION {primary,secondary,tertiary}
>>>      ...
>>>    END
>>> END
>>>
>>> The modifications to the code are fairly straightforward, and no
>>> backwards incompatibilities are expected as this is a new functionality
>>> that does not collide with previous mapserver expressions.
>>> The changes can be seen here:
>>>
>>> https://github.com/tbonfort/mapserver/commit/fae435d17b099485ab6792bfae3a7d8dd8992b4c
>>> . (you can ignore the changes to mapparser.*, they correct a bug in the
>>> IN parser and aren't related to the list operator)
>>>
>>> Our parser guru is OK with these changes, so I would like to vote to
>>> include this new expression for our 6.4 release.
>>>
>>> I'll start with my +1
>>>
>>> best regards,
>>> thomas
>>>
>>>
>>>   _______________________________________________
>>> mapserver-dev mailing list
>>> mapserver-dev at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/mapserver-dev
>>>
>>>
>>
>> --
>> Daniel Morissette
>> http://www.mapgears.com/
>> Provider of Professional MapServer Support since 2000
>>
>>
>> _______________________________________________
>> mapserver-dev mailing list
>> mapserver-dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/mapserver-dev
>>
>
>
>
> _______________________________________________
> mapserver-dev mailing listmapserver-dev at lists.osgeo.orghttp://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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-dev/attachments/20130506/5fd4b353/attachment.html>