logo separator

[mkgmap-dev] Performance of mkgmap.jar and splitter.jar

From Felix Hartmann extremecarver at googlemail.com on Sat Apr 4 11:43:18 BST 2009

Will do. 991 is now calculation on my stylefile2 since 43 minutes (so 
time to run has more than doubled). I will stop it now. Get hprof data 
from 988, then again use 991 and let it run while going outside for some 
I hope that command appends data and does not start the file from 
scratch when running mkgmap again.

In case you can't significantly speed up the changes, a parameter to 
turn that functions on/off is in my eyes desperately needed!

Mark Burton wrote:
> Hi Felix,
>> Will do. Until rev 984 performance is good (o.k got a bit slower, but 
>> that's o.k.), 988 got intolerable and 991 seems to need twice as much 
>> time as 988. Im still waiting for 991 to run through and then test on 
>> with -agentlib. I will continue testing and update you on the results in 
>> a few hours.
> 988 introduced the sorted road data so it's probably the road name
> sorting that's impacted the performance. I will look into that when the
> hprof data becomes available. It's always going to have some hit
> because you have to sort all of the road names in a tile. The way the
> sort is done needs looking at to see if it can be made more efficient.
> I make no claims that it is optimal at the moment.
> One thought that occurred to me a while back was that converting labels
> to their encoded form may be happening too early now. i.e. it would be
> more efficient to keep the labels as strings and then convert to the
> encoded form on output to the img file. That way, any operations on the
> labels (like sorting) could use the standard string functions. Also,
> correct me if I am wrong, but I don't think we handle multibyte
> characters yet (do we?) so if the labels are using some funky
> 16 bit character set, the sorting code as it is now would not work right
> anyway.
> As to why 991 is even slower than 988, I don't have a clue at this
> time.
> I am out this afternoon and this evening but if you post the hprof
> results I will look at them as soon as I can.
> Cheers,
> Mark
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20090404/33d719e1/attachment.html 

More information about the mkgmap-dev mailing list