r3239 in performance2 branch
Hi all, I've coded what I described here: http://gis.19327.n5.nabble.com/possible-tuning-for-evaluation-of-tags-tp5804... Depending on the options and style I see improvements between 1 % and 15 %. (1% for default style and options --route --preserve-element-order, up to 15% for complex styles like those from Minko or Henning) The more complex the style the more improvement you should see. The cache works like this: - common expressions (e.g. the barrier=* term in my example) in rules are detected when the style is read in, each of them has an int field that identifies a valid cache and the result of the evaluation (true/false) - when a new element is processed, the cache is reset (this just means one int value is incremented) - when a common expression is evaluated for the first time, the normal evaluation happens and the result is cached. - when the same expression is evaluated again the cached value is returned if the cache was not already reset - if an action adds or changes or deletes a tag, the cache is reset again (the more often this happens the less efective is the cache) All this requires more or less no extra heap. One remark regarding rules in <finalize> section: If I got that right, they are all evaluated, no matter what tags the OSM element has. For the "normal" rules we use a filter so that rules which cannot match are not evaluated. If you have time, please check if the branch really is faster and - even more important at this point - produces equal output. Gerd
Hi Gerd, below you'll find the compared times, mkgmap needs to compile the map.
From o5m-tile til img-tiles and gmapsupp.img. Seems to be, that you are on a good approach.
Henning trunk branch Germany 2110335 1830965 -13,24% Turkey 150734 137633 -8,69% Scandinavia 668798 647888 -3,13% Poland-Czech 721500 663320 -8,06% BeNeLux 539420 495979 -8,05% Patagonia 322421 308895 -4,20% MiddleAsia 60273 57082 -5,29% Alps 1866317 1724296 -7,61% NewZealand 328242 288148 -12,21% GreatBritain 701715 658821 -6,11% Arabia 268545 259366 -3,42% Canada-SW 369874 340675 -7,89% China 181014 163815 -9,50% India 184368 169392 -8,12%
Hi Henning, r3245 should be good now, faster and no known errors. I've also applied the oneway patch. Gerd Henning Scholland wrote
Hi Gerd,
below you'll find the compared times, mkgmap needs to compile the map.
From o5m-tile til img-tiles and gmapsupp.img. Seems to be, that you are on a good approach.
Henning
trunk branch Germany 2110335 1830965 -13,24% Turkey 150734 137633 -8,69% Scandinavia 668798 647888 -3,13% Poland-Czech 721500 663320 -8,06% BeNeLux 539420 495979 -8,05% Patagonia 322421 308895 -4,20% MiddleAsia 60273 57082 -5,29% Alps 1866317 1724296 -7,61% NewZealand 328242 288148 -12,21% GreatBritain 701715 658821 -6,11% Arabia 268545 259366 -3,42% Canada-SW 369874 340675 -7,89% China 181014 163815 -9,50% India 184368 169392 -8,12%
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/r3239-in-performance2-branch-tp5804618p580474... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Gerd, I also tested with r3245. For some regions this is even slower as r3225. But in general, it will save me (or lets say better my pc) a lot of time. Henning r3225 r3239 r3245 Germany 2110335 1830965 1775142 -13% -16% Turkey 150734 137633 133942 -9% -11% Scandinavia 668798 647888 647349 -3% -3% Poland-Czech 721500 663320 660533 -8% -8% BeNeLux 539420 495979 501059 -8% -7% Patagonia 322421 308895 324119 -4% 1% MiddleAsia 60273 57082 51164 -5% -15% Alps 1866317 1724296 1688913 -8% -10% NewZealand 328242 288148 287371 -12% -12% GreatBritain 701715 658821 601403 -6% -14% Arabia 268545 259366 235044 -3% -12% Canada-SW 369874 340678 317670 -8% -14% China 181014 163815 164700 -10% -9% India 184368 169392 149435 -8% -19% Am 30.04.2014 19:10, schrieb GerdP:
Hi Henning,
r3245 should be good now, faster and no known errors. I've also applied the oneway patch.
Gerd
Henning Scholland wrote
Hi Gerd,
below you'll find the compared times, mkgmap needs to compile the map.
From o5m-tile til img-tiles and gmapsupp.img. Seems to be, that you are on a good approach.
Henning
trunk branch Germany 2110335 1830965 -13,24% Turkey 150734 137633 -8,69% Scandinavia 668798 647888 -3,13% Poland-Czech 721500 663320 -8,06% BeNeLux 539420 495979 -8,05% Patagonia 322421 308895 -4,20% MiddleAsia 60273 57082 -5,29% Alps 1866317 1724296 -7,61% NewZealand 328242 288148 -12,21% GreatBritain 701715 658821 -6,11% Arabia 268545 259366 -3,42% Canada-SW 369874 340675 -7,89% China 181014 163815 -9,50% India 184368 169392 -8,12%
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/r3239-in-performance2-branch-tp5804618p580474...
Sent from the Mkgmap Development mailing list archive at Nabble.com.
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Henning, thanks for the info. I'll try to find out why Scandinavia and Patagonia don't show an improvement. One change is related to the number of routing nodes/arcs. The bigger the number the more CPU time is saved. I assume in these areas other algorithms are much more important. Gerd Henning Scholland wrote
Hi Gerd, I also tested with r3245. For some regions this is even slower as r3225. But in general, it will save me (or lets say better my pc) a lot of time.
Henning
r3225 r3239 r3245 Germany 2110335 1830965 1775142 -13% -16% Turkey 150734 137633 133942 -9% -11% Scandinavia 668798 647888 647349 -3% -3% Poland-Czech 721500 663320 660533 -8% -8% BeNeLux 539420 495979 501059 -8% -7% Patagonia 322421 308895 324119 -4% 1% MiddleAsia 60273 57082 51164 -5% -15% Alps 1866317 1724296 1688913 -8% -10% NewZealand 328242 288148 287371 -12% -12% GreatBritain 701715 658821 601403 -6% -14% Arabia 268545 259366 235044 -3% -12% Canada-SW 369874 340678 317670 -8% -14% China 181014 163815 164700 -10% -9% India 184368 169392 149435 -8% -19%
Am 30.04.2014 19:10, schrieb GerdP:
Hi Henning,
r3245 should be good now, faster and no known errors. I've also applied the oneway patch.
Gerd
Henning Scholland wrote
Hi Gerd,
below you'll find the compared times, mkgmap needs to compile the map.
From o5m-tile til img-tiles and gmapsupp.img. Seems to be, that you are on a good approach.
Henning
trunk branch Germany 2110335 1830965 -13,24% Turkey 150734 137633 -8,69% Scandinavia 668798 647888 -3,13% Poland-Czech 721500 663320 -8,06% BeNeLux 539420 495979 -8,05% Patagonia 322421 308895 -4,20% MiddleAsia 60273 57082 -5,29% Alps 1866317 1724296 -7,61% NewZealand 328242 288148 -12,21% GreatBritain 701715 658821 -6,11% Arabia 268545 259366 -3,42% Canada-SW 369874 340675 -7,89% China 181014 163815 -9,50% India 184368 169392 -8,12%
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/r3239-in-performance2-branch-tp5804618p580474...
Sent from the Mkgmap Development mailing list archive at Nabble.com.
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/r3239-in-performance2-branch-tp5804618p580485... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Henning, in Patagonia the poor performance is caused by the LocationHook which has a lot of work to do. The reason are the extremely complex boundary relations like this one http://www.openstreetmap.org/browse/relation/1981462 They also cause a lot of CPU usage in the MultiPolygonRelation class. I've added a note that these administrative boundaries are too complex, but I have no idea if anybody cares about it, and I don't dare to change them. For Scandinavia I see different numbers: r3246: 460686ms r3247 + small patch: 410354ms which gives ~-11% Maybe your server was busy with something else while compiling Scandinavia with r3245, or the small patch I am working on is better than expected ;-) Gerd
Date: Thu, 1 May 2014 12:42:06 -0700 From: gpetermann_muenchen@hotmail.com To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] r3239 in performance2 branch
Hi Henning,
thanks for the info. I'll try to find out why Scandinavia and Patagonia don't show an improvement. One change is related to the number of routing nodes/arcs. The bigger the number the more CPU time is saved. I assume in these areas other algorithms are much more important.
Gerd
Henning Scholland wrote
Hi Gerd, I also tested with r3245. For some regions this is even slower as r3225. But in general, it will save me (or lets say better my pc) a lot of time.
Henning
r3225 r3239 r3245 Germany 2110335 1830965 1775142 -13% -16% Turkey 150734 137633 133942 -9% -11% Scandinavia 668798 647888 647349 -3% -3% Poland-Czech 721500 663320 660533 -8% -8% BeNeLux 539420 495979 501059 -8% -7% Patagonia 322421 308895 324119 -4% 1% MiddleAsia 60273 57082 51164 -5% -15% Alps 1866317 1724296 1688913 -8% -10% NewZealand 328242 288148 287371 -12% -12% GreatBritain 701715 658821 601403 -6% -14% Arabia 268545 259366 235044 -3% -12% Canada-SW 369874 340678 317670 -8% -14% China 181014 163815 164700 -10% -9% India 184368 169392 149435 -8% -19%
Am 30.04.2014 19:10, schrieb GerdP:
Hi Henning,
r3245 should be good now, faster and no known errors. I've also applied the oneway patch.
Gerd
Henning Scholland wrote
Hi Gerd,
below you'll find the compared times, mkgmap needs to compile the map.
From o5m-tile til img-tiles and gmapsupp.img. Seems to be, that you are on a good approach.
Henning
trunk branch Germany 2110335 1830965 -13,24% Turkey 150734 137633 -8,69% Scandinavia 668798 647888 -3,13% Poland-Czech 721500 663320 -8,06% BeNeLux 539420 495979 -8,05% Patagonia 322421 308895 -4,20% MiddleAsia 60273 57082 -5,29% Alps 1866317 1724296 -7,61% NewZealand 328242 288148 -12,21% GreatBritain 701715 658821 -6,11% Arabia 268545 259366 -3,42% Canada-SW 369874 340675 -7,89% China 181014 163815 -9,50% India 184368 169392 -8,12%
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/r3239-in-performance2-branch-tp5804618p580474...
Sent from the Mkgmap Development mailing list archive at Nabble.com.
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/r3239-in-performance2-branch-tp5804618p580485... Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
participants (3)
-
Gerd Petermann -
GerdP
-
Henning Scholland