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

Sat Apr 4 11:33:49 BST 2009

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