[mkgmap-dev] [PATCH V3]mkgmap performance

Tue Dec 27 13:49:23 GMT 2011

Hello Steve,

Steve Ratcliffe wrote
> 
>> What is causing mkgmap to produce different results each time when it
>> executes? This makes optimization very difficult because one cannot
>> simply
>> compare old and new result.
> 
> I don't know why this happens now, and it really shouldn't (apart from 
> the timestamps which are easy to ignore), I will try to find out why.
> 
thanks, tt would be great if this could be changed.

> I tried your patches on my laptop but haven't seen such a big 
> difference, perhaps 5% at most, and very little difference on some 
> individual tiles.
> 
I assume the performance improvements depend heavily on the hardware, the OS
and the JVM that is used.
I have a dual boot system with WinXP+sun jdk  and a 64bit Ubuntu with
openJDK . I see very different results.
Esp. interesting is that splitter is much faster on linux, while mkgmap is
much slower, even with small input files were heap size doesn't matter.
Also, it seems to be important to find a proper tile size in splitter. If I
use large tiles (high max-nodes value), mkgmap might not have enough memory
for max-jobs threads. Since each threads has a zick-zack type curve in heap
uage, it is likely to reach the availabe heap maximum when setting max-jobs
to a high value.
In my test environment, the CPU still is the bottleneck. 

Ciao,
Gerd

--
View this message in context: http://gis.638310.n2.nabble.com/PATCH-mkgmap-performance-part-2-tp7123938p7130175.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.