Hi Lambertus, okay, regarding performance I think it makes no sense to use a small max-areas value. The rule seems to be simple: The more passes, the longer the run time. On the other hand, it would be good to know that the results are exactly the same (same problem-list, same *.osm.gz, same areas.list). I've never tested that with planet, only with small areas. Gerd Date: Fri, 30 Nov 2012 19:57:47 +0100 From: osm@na1400.info To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] splitter r247 Maybe because I forgot to change the -max-areas setting the split took a lot longer then expected. It even did not finish yet. CPU usage is around 1 to 4% now, this doesn't look good. I've attached the log. The commandline I used was: java -agentlib:hprof=cpu=samples,depth=20 -XX:-HeapDumpOnOutOfMemoryError -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -Xmx6000m -jar splitter.jar --output=xml --keep-complete --overlap=0 --no-trim --mapid=1 --max-nodes=1500000 --max-areas=512 --write-kml=initial.kml --geonames-file=cities15000.zip planet-latest.osm.pbf I'll start the split again using --max-areas=2048 On 30-11-12 01:53, GerdP wrote: > > The results were ok, only runtime and memory usage was too high in > your case. r250 corrects this. > > If you want to provide new logs, please run this version with java > -agentlib:hprof=cpu=samples,depth=20 -XX:-HeapDumpOnOutOfMemoryError > -XX:+PrintGCTimeStamps +PrintGCDetails -Xmx6000m -jar splitter.jar > .... --max-areas=2048 > > This should result in max. 2 hours runtime. > > If you want to compare with the previous results, try also with > --max-areas=255 > > Please send me the splitter log and the java.hprof . > > Gerd > _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev