[mapserver-dev] [performance] mapserver list expressions

[Stephen Woodbridge]

+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 
> <mailto: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
>         <mailto: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 <mailto: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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-dev/attachments/20130405/0ca4c322/attachment.html>