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