<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>Hi all,<br><br>I've coded what I described here:<br><br><a href="http://gis.19327.n5.nabble.com/possible-tuning-for-evaluation-of-tags-tp5804504.html" target="_blank">http://gis.19327.n5.nabble.com/possible-tuning-for-evaluation-of-tags-tp5804504.html</a><br><br>Depending on the options and style I see improvements between 1 % and 15 %.<br>(1% for default style and options --route --preserve-element-order,<br>up to 15% for complex styles like those from Minko or Henning)<br><br>The more complex the style the more improvement you should see.<br><br>The cache works like this:<br>- common expressions (e.g. the barrier=* term in my example) <br>in rules are detected when the style is read in, each of them has an<br>int field that identifies a valid cache and the result of the evaluation (true/false)<br>- when a new element is processed, the cache is reset (this just means one int value is incremented)<br>- when a common expression is evaluated for the first time, the normal evaluation<br>happens and the result is cached.<br>- when the same expression is evaluated again the cached value is returned if the cache was not already reset<br>- if an action adds or changes or deletes a tag, the cache is reset again (the more often this happens the less<br>efective is the cache)<br>All this requires more or less no extra heap.<br><br>One remark regarding rules in <finalize> section:<br>If I got that right, they are all evaluated, no matter what tags the OSM element <br>has. <br>For the "normal" rules we use a filter so that rules which cannot match are<br>not evaluated.<br><br>If you have time, please check if the branch really is faster and - even more important at<br>this point - produces equal output.<br><br>Gerd<br><br> </div></body>
</html>