[mkgmap-dev] [PATCH V3]mkgmap performance
From WanMil wmgcnfg at web.de on Sun Jan 1 19:31:05 GMT 2012
Hi Gerd, > > 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. Did you try to use another storage mechanism within the removeShortArcs... method? I don't like storing the infos of the short arcs in *all* coords. Your patch reduces the memory footprint of the Coord object (great!). But I think information should be as local as possible. > > > >> * 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. Great! > > >> * 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 > All in all I see speed improvements using the patch. So after the Coord question is cleared I would like to commit that if nobody vetoes and you agree. Thanks! WanMil
- Previous message: [mkgmap-dev] Garmin codes for Great Britain National Grid
- Next message: [mkgmap-dev] [PATCH V3]mkgmap performance
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the mkgmap-dev mailing list