logo separator

[mkgmap-dev] [PATCH v2] LocationHook speedup

From GerdP gpetermann_muenchen at hotmail.com on Sat Dec 31 13:42:14 GMT 2011

Hi WanMil,

Yes , I think you always have to look at both values, esp. with java and GC.
If you optimize a function by allocating a lot of temp. objects, you might
see better runtime in this function but overall runtime may be worse because
GC gets very busy after executing the function.


WanMil wrote
> now we have the problem of how to measure the runtime performance.
> I have compared unpatched and patched mkgmap. Both versions contain the 
> time output of the patched version. I have used one thread only with 15 
> european tiles (widely spread over europe) and compare the summarized 
> runtime of the LocationHook only because that's what should be improved 
> by the patch.
> I have done 4 runs of each version. The mean values are:
> r2154: 65280 ms for LocationHook, 335325 ms overall runtime
> patch: 55173 ms for LocationHook, 313082 ms overall runtime
> diff:  10107 ms improvement Hook, 22243 ms improvement overall
> The overall improvement is a bit problematic because I would expect that 
> it is close to the LocationHook improvement but its twice. The patch 
> uses less memory and therefore the GC (which probably runs outside the 
> Hook) must do less work. But I am unsure if that's the reason for the 
> good overall improvement.

View this message in context: http://gis.638310.n2.nabble.com/PATCH-v1-LocationHook-speedup-tp7135704p7140417.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.

More information about the mkgmap-dev mailing list