Hi Gerd, please find attached v2 of the max-jobs patch. This version additionally catches out of heap memory exceptions and displays a message suggesting either the use of the Java -Xmx option to increase the available heap memory or the mkgmap --max-jobs option with a smaller value to reduce the memory requirement (the latter is suggested only if using more than one thread).
How does that seem? Regards, Mike -----Original Message----- From: Gerd Petermann [mailto:[email protected]] Sent: 05 February 2018 07:28 To: Mike Baggaley <[email protected]>; 'Development list for mkgmap' <[email protected]> Subject: Re: [mkgmap-dev] max-jobs patch Hi Mike, thought about this again. Maybe this change is too simple. With multiple jobs one also needs more heap (-Xmx JRE option). If you create rather large tiles with splitter (max-nodes=1600000) you need 0.5 - 1 GB for each job. Not sure what happens when a user creates a map with 10 tiles on an 8-core machine without any -Xmx option. I fear this will result in OutOfMemory exception, so better check the available heap as well. Gerd ________________________________________ Von: mkgmap-dev <[email protected]> im Auftrag von Mike Baggaley <[email protected]> Gesendet: Sonntag, 4. Februar 2018 15:14 An: 'Development list for mkgmap' Betreff: [mkgmap-dev] max-jobs patch Hi Gerd, Please find attached a patch that amends the default behaviour if the --max-jobs option is not specified, to using a value equal to the number of CPU cores, as suggested in a previous post. The documentation is also amended to reflect the change. This halves the execution time of mkgmap for building a map of Staffordshire on my 8-core PC when --max-jobs is not specified (I didn't know about this option previously and was unaware the performance could have been improved). Cheers, Mike
maxjobs-v2.patch
Description: Binary data
_______________________________________________ mkgmap-dev mailing list [email protected] http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
