[mapserver-dev] [performance] mapserver list expressions

[thomas bonfort]

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/**
>> fae435d17b099485ab6792bfae3a7d**8dd8992b4c<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<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<http://lists.osgeo.org/mailman/listinfo/mapserver-dev>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-dev/attachments/20130404/e008d2e8/attachment.html>