[BGL] Very slow adjacency_list deallocation/reallocation for debug builds

Does anyone know a way to speed up adjacency_list deallocation for debug builds? I've done some timing tests (see code below - should build as-is in VC9) and found the adjacency_list creates quite quickly, but is terrible during deallocation (actually, it can be as bad on creation of the graph, too, if you are building up the graph incrementally using a vecS for your vertex storage that requires reallocation as the size grows). In a release build, everything is blazing fast, but it's so slow when linked against the debug CRT that I essentially cannot debug my app. And the graph doesn't have to be too big (see code below, 50K results in a deallocation time of 171 sec if I use vecS and 268 sec if I use listS, and that's on a quite good workstation; my production graphs are > 100K vertices). BTW, I'm building with Visual C++ 9 (2008).
#include

On Tue, Feb 23, 2010 at 2:27 PM, T MacAdam
Does anyone know a way to speed up adjacency_list deallocation for debug builds?
The technique I use isn't documented, but it has been discussed before on the list. It also uses implementation details so it's not guaranteed to work across releases. myGraph->m_vertices is the vector storing the vertices. Just call reserve() on it when you know the number of vertices ahead of time. If you want to do the same with edges use myGraph->m_edges, but you're using a list for the edge storage so it doesn't apply to this case. It would be nice if there was a way to reserve storage for vertices and edges in the actual graph interface. HTH, --Michael Fawcett

On Tue, Feb 23, 2010 at 2:27 PM, T MacAdam
Does anyone know a way to speed up adjacency_list deallocation for debug builds? I've done some timing tests (see code below - should build as-is in VC9) and found the adjacency_list creates quite quickly, but is terrible during deallocation (actually, it can be as bad on creation of the graph, too, if you are building up the graph incrementally using a vecS for your vertex storage that requires reallocation as the size grows). In a release build, everything is blazing fast, but it's so slow when linked against the debug CRT that I essentially cannot debug my app. And the graph doesn't have to be too big (see code below, 50K results in a deallocation time of 171 sec if I use vecS and 268 sec if I use listS, and that's on a quite good workstation; my production graphs are > 100K vertices). BTW, I'm building with Visual C++ 9 (2008).
It may be entirely dependent upon MS' std library. I don't think that adjacency_list does anything spectacular on destruction, but I could be wrong. Andrew Sutton andrew.n.sutton@gmail.com
participants (3)
-
Andrew Sutton
-
Michael Fawcett
-
T MacAdam