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.
Gerd 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. _______________________________________________ mkgmap-dev mailing list [email protected] http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
