[mapserver-dev] [performance] mapserver list expressions

Smith, Michael ERDC-RDE-CRREL-NH Michael.Smith at erdc.dren.mil
Wed Apr 3 08:58:51 PDT 2013


Thomas,

Nice work.

+1

Mike

--
Michael Smith
US Army Corps
Remote Sensing GIS/Center

From: thomas bonfort <thomas.bonfort at gmail.com<mailto:thomas.bonfort at gmail.com>>
Date: Wednesday, April 3, 2013 11:16 AM
To: MapServer Dev Mailing List <mapserver-dev at lists.osgeo.org<mailto:mapserver-dev at lists.osgeo.org>>
Subject: [mapserver-dev] [performance] mapserver list expressions
Resent-From: Michael Smith <michael.smith at usace.army.mil<mailto:michael.smith at usace.army.mil>>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-dev/attachments/20130403/50a51266/attachment.html>


More information about the mapserver-dev mailing list