logo separator

[mkgmap-dev] r3239 in performance2 branch

From Gerd Petermann gpetermann_muenchen at hotmail.com on Tue Apr 29 21:15:52 BST 2014

Hi all,

I've coded what I described here:

http://gis.19327.n5.nabble.com/possible-tuning-for-evaluation-of-tags-tp5804504.html

Depending on the options and style I see improvements between 1 % and 15 %.
(1% for default style and options --route --preserve-element-order,
up to 15% for complex styles like those from Minko or Henning)

The more complex the style the more improvement you should see.

The cache works like this:
- common expressions (e.g. the barrier=* term in my example) 
in rules are detected when the style is read in, each of them has an
int field that identifies a valid cache and the result of the evaluation (true/false)
- when a new element is processed, the cache is reset (this just means one int value is incremented)
- when a common expression is evaluated for the first time, the normal evaluation
happens and the result is cached.
- when the same expression is evaluated again the cached value is returned if the cache was not already reset
- if an action adds or changes or deletes a tag, the cache is reset again (the more often this happens the less
efective is the cache)
All this requires more or less no extra heap.

One remark regarding rules in <finalize> section:
If I got that right, they are all evaluated, no matter what tags the OSM element 
has. 
For the "normal" rules we use a filter so that rules which cannot match are
not evaluated.

If you have time, please check if the branch really is faster and - even more important  at
this point - produces equal output.

Gerd

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20140429/dda20341/attachment.html>


More information about the mkgmap-dev mailing list