logo separator

[mkgmap-dev] Possible optimization of StyledConverter

From GerdP gpetermann_muenchen at hotmail.com on Thu Jan 5 05:41:25 GMT 2012

Steve, WanMil,

the discussion about a prepro for styles inspired me to think about a
compiler/optimizer for style rules.
The point that I have in mind is this: Style files typically have many
different rules starting with e.g. 
highway=* & ...
The current iplementation in RuleSet.java and RuleIndex.java will first
create a set of all rules that might match for the existing tags of a given
element. Next, it processes each rule until the element is done.
Let's assume an element that has tag "highway" and maybe 4 other tags
If we have twenty rules with highway=* and none of them matches, we'll call
getTag("highway") twenty times, always with the same result. Although
getTag() is not very complex, it still means a lookup in a hash table. 
I see two possible optimizations here:
1) Combine rules that start with the same expression, e.g. highway=*, so
that we don't evaluate tags again and again. In the past I used parser
generator tools like lexx+yacc. I  have the feeling that the rule
interpretation is also something that could be done by a table driven

2) A bit off-topic: Use a short instead of a String for the keys of Tags. I
think even complex styles will not use more than a few hundred different tag
keys. If all used tag keys are stored in an array, we can refer to the
position in that array. Some weeks ago I coded that and it turned out to
save some CPU cycles because Tags.keyPos()  is simpler, but it also required
changes in many sources and I found other patches providing more improvement
with smaller changes.

What do you think about this?

P.S. A storm kept me awake all night long, so maybe I am writing nonsense

View this message in context: http://gis.638310.n2.nabble.com/Possible-optimization-of-StyledConverter-tp7153308p7153308.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.

More information about the mkgmap-dev mailing list