[mkgmap-dev] [PATCH]mkgmap performance part 2

Mon Dec 26 19:06:18 GMT 2011

Hi Gerd,

the patches looks good to me. Thanks for your work!
I have commited the part for the LocationHook.

For the other things I have some questions:
* 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...
* 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.
* I propose to use an ArrayList instead of HashSet in line 157 of RuleIndex
* 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?

WanMil

> Hello list,
>
> I got no feedback regarding my last performance patch for mkgmap, so I don't
> know if nobody tested it. Anyway, here are a few more small suggestions for
> changes (can be applied
> http://gis.638310.n2.nabble.com/file/n7123938/mkgmap_performance_2.patch
> mkgmap_performance_2.patch  on r2145 and gmap-mdr branch 2144 as well) :
> On my dual-core machine, creating a gmapsupp.img of ~ 91MB (Niedersachsen)
> with max-jobs=2 required ~ 352 secs with r2145, and 268 secs (~ 25% less)
> with my previous patch + this one, so I think it is worth trying.
>
> For removeShortArcsByMergingNodes:
> - The IdentityHashMap arcCounts counts arcs, but the only result that is
> used is wether or not an arc was found. My patch replaces this frequently
> used map and uses a bit in Coord instead.
>
> - the current algorithmn tries to find replacements for each point, this is
> quite costly. One more bit in Coord reduces the number of loops from>
> 1.000.000 to ~1000.
>
> For LocationHook:
> I've replaced the getUsedLocationTags() by testHasAllTags(). This just
> returns true if all tags in List remainingLevels are existing, instead of
> merging HashSets to get the same result.
>
> For RuleSet / RuleIndex:
> I've replaced the HashSet<Integer>  by BitSet. This is faster because we
> don't have to use
> Collections.sort(candidates);
> to handle duplicate rules.
>
> Gerd
>
>
>
> --
> View this message in context: http://gis.638310.n2.nabble.com/PATCH-mkgmap-performance-part-2-tp7123938p7123938.html
> Sent from the Mkgmap Development mailing list archive at Nabble.com.
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev