[mkgmap-dev] Java tuning hint

Fri May 9 07:18:44 BST 2014

Hi Bernd,

It is difficult to say how many strings are kept in the table when 
your have 4 threads in parallel, but it seems the value 100003 fits quite well.
Larger values did not improve anything in my tests (I ignore changes < 2 seconds).

BTW: It's very difficult to get exact values. 
If you execute mkgmap two times after not using it for a while
the 2nd run will always be faster because disk caches are already 
filled with good values.
So, you first have to execute mkgmap a few times with exactly the
same parms and input files to find out how many seconds 
it executes on average and how large the measurement error is.
You may already see 5 % difference here
when using multiple threads (--max-jobs), because sometimes
a worse case happens, sometimes not. This also seems to
depend on actions from JRE like just in time (JIT) compiles etc, 
not talking about other background programs like system updates, 
downloads, virus scanners, media players etc.

The worst case that can happen is that you find a good value for 
one set of input files which is bad for many other sets of input files.

Gerd

> From: weigelt.bernd at web.de
> To: mkgmap-dev at lists.mkgmap.org.uk
> Date: Thu, 8 May 2014 18:28:22 +0200
> Subject: Re: [mkgmap-dev] Java tuning hint
> 
> Am Donnerstag, 8. Mai 2014, 17:33:22 schrieb Gerd Petermann:
> 
> Hello Gerd
> 
> I've made three tests with my bonn extract
> 
> without -XX:StringTableSize
> Time started: Thu May 08 17:57:43 CEST 2014
> Time finished: Thu May 08 18:04:54 CEST 2014
> Total time taken: 430804ms
> 
> with -XX:StringTableSize=100003
> Time started: Thu May 08 18:07:33 CEST 2014
> Time finished: Thu May 08 18:14:20 CEST 2014
> Total time taken: 406425ms
> 
> with -XX:StringTableSize=1000003
> time started: Thu May 08 18:16:20 CEST 2014
> Time finished: Thu May 08 18:23:06 CEST 2014
> Total time taken: 405556ms
> 
> This are tests on my small laptop with 3.6 GB RAM with 64bit Linux
> 
> Bernd
> 
> > I tried both, and the smaller values seemed to work better for mkgmap.
> > I guess it depends on the input files what value is best, but at least 
> > the default 1009 doesn't work well, so any much higher prime value should
> > help.
> 
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20140509/08fb0688/attachment-0001.html>