[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.
- Previous message: [mkgmap-dev] [PATCH]mkgmap performance part 2
- Next message: [mkgmap-dev] [PATCH V3]mkgmap performance
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the mkgmap-dev mailing list