[mapserver-dev] [performance] mapserver list expressions
thomas bonfort
thomas.bonfort at gmail.com
Thu Apr 4 10:39:35 PDT 2013
On 4 April 2013 19:21, Daniel Morissette <dmorissette at mapgears.com> wrote:
> Thank you!
>
> BTW, will string delimiters be honoured inside the list expression? e.g.
>
>
> LAYER
> ...
> CLASSITEM "type"
> CLASS
> EXPRESSION {"a","b","a,b","4,500"}
> ...
> END
> END
No they will not be supported, the expression evaluator is very fast but
rudimentary (the provided list isn't split up into a char* array, we just
strchr() look for commas, and strncmp with the attribute value). If the
need arises this could be added in a second phase, although I'm not sure
how that would be handled by the lexer yet.
I'll add a note about this in the RFC.
thanks,
thomas
>
>
>
>
> On 13-04-04 12:39 PM, thomas bonfort wrote:
>
>> Daniel,
>>
>> done:
>> https://github.com/mapserver/**docs/blob/branch-6-2/en/**
>> development/rfc/ms-rfc-95.txt<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 <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/__fae435d17b099485ab6792bfae3a7d__8dd8992b4c>
>>
>> <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 <mailto:mapserver-dev at lists.**
>> osgeo.org <mapserver-dev at lists.osgeo.org>>
>> http://lists.osgeo.org/__**mailman/listinfo/mapserver-dev<http://lists.osgeo.org/__mailman/listinfo/mapserver-dev>
>>
>> <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 <mailto:mapserver-dev at lists.**osgeo.org<mapserver-dev at lists.osgeo.org>
>> >
>> http://lists.osgeo.org/__**mailman/listinfo/mapserver-dev<http://lists.osgeo.org/__mailman/listinfo/mapserver-dev>
>> <http://lists.osgeo.org/**mailman/listinfo/mapserver-dev<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<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/ebcc2284/attachment.html>
More information about the mapserver-dev
mailing list