logo separator

[mkgmap-dev] [PATCH V3]mkgmap performance

From GerdP gpetermann_muenchen at hotmail.com on Tue Dec 27 09:35:12 GMT 2011

WanMil wrote
> 
> * Can you please add some javadoc to the new methods? I know the old 
> methods often do not have javadocs but that shouldn't be continued...
> 
I totally agree. The attached correction contains comments. I am a little
bit in trouble with this because the new methods and the corresponding flags
in Coord are only meaningfull inside the existing
removeShortArcsByMergingNodes() method of ElementSaver, but I think the
performance improvement is worth enough to allow this rather bad coding
style.


 
> * RuleIndex.getRulesForTag returns a BitSet that can be modified 
> externally. This is no good style. I know that the BitSet is not 
> modified externally so it's not a bug. But at least is should be 
> documented in the javadoc that the returned BitSet *must not* be modified.
> 
In fact, the method was wrong because it evtl. modified by mistake the
BitSet in tagVals. This is corrected with the new patch which returns a
newly created BitSet.

 
> * I propose to use an ArrayList instead of HashSet in line 157 of
> RuleIndex
> 
OK, changed. This part of the code is not performance critical, so I wanted
to keep the changes small.


 
> * RuleIndex line 175: The set.clear(i) method changes the BitSet in 
> tagVals/tagnames directly. The unpatched mkgmap is working on a copy. 
> Can you please check carefully if your version is correct?
> 
Good catch, my version was definetly wrong. This is also corrected with the
new patch.

The new patch adds one more small change:
In removeShortArcsByMergingNodes() Coord.distance() is only called if we
really have to calculate the length of the arc. If parameter
remove-short-arcs is used without a value (or with remove-short-arcs=0),
there is no need to calculate the distance, we just need to know if the two
points are equal.

I also have one question:
What is causing mkgmap to produce different results each time when it
executes? This makes optimization very difficult because one cannot simply
compare old and new result.

http://gis.638310.n2.nabble.com/file/n7129718/mkgmap_performance_3.patch
mkgmap_performance_3.patch 

Ciao,
Gerd


--
View this message in context: http://gis.638310.n2.nabble.com/PATCH-mkgmap-performance-part-2-tp7123938p7129718.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.



More information about the mkgmap-dev mailing list