[pgrouting-dev] Fixes for Bidirectional code just checked in

[Alec Gosse]

It would seem that it was simply running out of memory due to giant default vector resize requests. Adding 
m_vecEdgeVector.reserve(edge_count);
before the loop calling addEdge(..) in the construct_graph function seems to do the trick. Probably best to do m_vecNodeVector.reserve(maxNode) as well, just for good measure;

I recall seeing something similar to this discussed, but perhaps it was somewhere else in the code.

Alec




On Jun 4, 2013, at 4:34 PM, Stephen Woodbridge <woodbri at swoodbridge.com> wrote:

> On 6/4/2013 3:53 PM, Alec Gosse wrote:
>> Hello,
>> 
>> I've just pulled from the develop branch and built fresh and I'm
>> getting a server crash from pgr_bdastar. If I run exactly the same
>> thing using pgr_astar, it works. This is using postgres 9.2.4 and
>> postgis 2.0.3 from Homebrew on Mac 10.8.3
> 
> I'm using pg9.2.4 and postgis 2.0.x or 2.1.0beta3dev and I fixed these issues I thought. Evidently not.
> 
>> I'm still working on a bulk routing function using bdastar, but just
>> realized that the regular version was crashing without my
>> modifications. I'm happy to try to track this down, but have little
>> knowledge of how to debug within postgresql. Any pointers would be
>> appreciated.
> 
> OK, start by uncommenting #define DEBUG 1 in both the C and C++ code. Then add more DBG('I got here message\n"). In the C++ code these messages get written to a file '/tmp/sew-debug' and you can do a tail -f on that in another window to see your progress.
> 
> This is likely a issue in the C++ code but it may also be something systemic about the way we are integrating code. If you build your own postgresql you might want to rebuild it with --enable-cassert option to configure which will put the database backend into a more rigorous memory check mode.
> 
> That is a start, I would be appy to help more if I can.
> 
> Thanks,
>  -Steve
> 
>> Best, Alec
>> 
>> 
>> 
>> 
>> On Jun 1, 2013, at 2:13 PM, Stephen Woodbridge
>> <woodbri at swoodbridge.com> wrote:
>> 
>>> Hi all,
>>> 
>>> I think I have just submitted changes to the bidirectional dijkstra
>>> and astar routines the resolve the server crashes we were seeing.
>>> This closes on major outstanding bug against 2.0.
>>> 
>>> Razequl,
>>> 
>>> I made two simple changes to your code BiDirDijkstra.cpp and the
>>> astar version:
>>> 
>>> 1. in BiDirDijkstra::initall I add: m_vecNodeVector.reserve(maxNode
>>> + 1);
>>> 
>>> 2. in BiDirDijkstra::bidir_dijkstra I move the call to
>>> initall(maxNode); to before construct_graph(edges, edge_count,
>>> maxNode);
>>> 
>>> This does two major things:
>>> 
>>> 1. std::vector doubles the size of the array every time it needs to
>>> increase its size and then needs to copy the old data to the new
>>> area.
>>> 
>>> 2. reserve() pre allocates all the memory we need once, which avoid
>>> realloc memory fragmentation and avoids the copy each time it
>>> reallocs so this improves performance.
>>> 
>>> Anytime you know how much space you are going to need you should
>>> reserve it up front.
>>> 
>>> So things look good for now.
>>> 
>>> Thanks, -Steve _______________________________________________
>>> pgrouting-dev mailing list pgrouting-dev at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/pgrouting-dev
>> 
>> _______________________________________________ pgrouting-dev mailing
>> list pgrouting-dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/pgrouting-dev
>> 
> 
> _______________________________________________
> pgrouting-dev mailing list
> pgrouting-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/pgrouting-dev