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-tp7123938p71... Sent from the Mkgmap Development mailing list archive at Nabble.com.