[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 mountainbiking. 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! Cheers, Felix 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
- Previous message: [mkgmap-dev] Performance of mkgmap.jar and splitter.jar
- Next message: [mkgmap-dev] Performance of mkgmap.jar and splitter.jar
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the mkgmap-dev mailing list