[PATCH v2] - Sub-optimal fix to limit excessive inter-node arc length
Folks, This is a revamped version of my earlier code to limit the length of arcs to avoid routing problems due to the arc length being truncated. As before, this patch should be thought of as a temporary work around rather than the ultimate solution. Having said that, I think it would be good to incorporate this in the trunk because some maps (routing) will be broken without it. I think that the only reason that this patch should not be used is if it introduces too much of a time penalty when processing big maps. So I would be very grateful if people who are processing big maps could try this patch and let me know whether the performance hit is acceptable or not. If it isn't then I guess we will need an option to disable the fix. Cheers, Mark
On Sun, Apr 26, 2009 at 12:47 PM, Mark Burton <markb@ordern.com> wrote:
I think that the only reason that this patch should not be used is if it introduces too much of a time penalty when processing big maps. So I would be very grateful if people who are processing big maps could try this patch and let me know whether the performance hit is acceptable or not. If it isn't then I guess we will need an option to disable the fix.
I performed a very non-scientific test on the map of Germany which I regularly compile. Using SVN 1022 without the patch, compiling the 35 tiles took 2 hours and 6 minutes. With the patch installed, the compile time was 1 hour 53 minutes. I would say that the difference is statistically insignificant, ;-) although I was surprised that the compilation with the patch was about 13 minutes faster, but this could be due to other processes consuming system resources. (As I said, my test was highly unscientific.) I'll try to test again with v3 of this patch, but it seems that performance is not an issue, apparently. Cheers.
Hi Clinton, Many thanks for the feedback.
I would say that the difference is statistically insignificant, ;-) although I was surprised that the compilation with the patch was about 13 minutes faster, but this could be due to other processes consuming system resources. (As I said, my test was highly unscientific.)
I'll try to test again with v3 of this patch, but it seems that performance is not an issue, apparently.
Hmm, perhaps we can just go for enabling it all the time rather than having an option. The extra calls to Coord.distance() are obviously just getting lost in the noise. Good, that makes life simple! Cheers, Mark
participants (2)
-
Clinton Gladstone -
Mark Burton