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.

Ciao,
Gerd

 		 	   		  
-------------- 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