logo separator

[mkgmap-dev] [PATCH V3]mkgmap performance

From Gerd Petermann gpetermann_muenchen at hotmail.com on Mon Jan 2 07:10:15 GMT 2012

Hi WanMil,
> >
> > 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.
reg. memory footprint: I fear Coord instances will still require 16 bytes because of the padding that happens. 
I tried another trick which required an additional integer field in Coord, so I compressed the boolean fields. Later I removed the integer field but kept the rest.
We can change that to boolean without problems.

reg. "local information": I totally agree, but I found no better way, and it saved a lot of time on my system.
The performance improvement comes from the fact that we can very quickly extract a boolean value from a known object. It will take more time to find something in a different structure. If you have an idea, let me know and I'll try,
else we can simply drop that part of the patch and keep Coord.java and ElementSaver.java unchanged.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20120102/2c0376ee/attachment.html 

More information about the mkgmap-dev mailing list