[Boost.Graph] Profiling using the graph library
Hello, I use the boost graph library (Version 1.33.1 of Boost) for my programming task. I wanted to profile my program with gprof. I compilated the source code with the -pg option and linked it also with that option. Now I'm examining the output file of gprof. Some functions of boost graph library are not explicitly listed there althogh I use them. These functions are: vertices() add_edge() What I see instead are some complicated functions. I have copied them here from my gprof-Output. But where are vertices() and add_edge()? Or are they meant by these complicated functions. Best regards Ewgenij Sokolovski 1) std::pair<std::vector<boost::detail::sei_<unsigned long, std::_List_iterator<boost::list_edge<unsigned long, boost::property<boost::edge_bundle_t, float, boost::no_property> > >, boost::property<boost::edge_bundle_t, float, boost::no_property> >, std::allocator<boost::detail::sei_<unsigned long, std::_List_iterator<boost::list_edge<unsigned long, boost::property<boost::edge_bundle_t, float, boost::no_property> > >, boost::property<boost::edge_bundle_t, float, boost::no_property> > > >::iterator, bool> boost::graph_detail::push<std::vector<boost::detail::sei_<unsigned long, std::_List_iterator<boost::list_edge<unsigned long, boost::property<boost::edge_bundle_t, float, boost::no_property> > >, boost::property<boost::edge_bundle_t, float, boost::no_property> >, std::allocator<boost::detail::sei_<unsigned long, std::_List_iterator<boost::list_edge<unsigned long, boost::property<boost::edge_bundle_t, float, boost::no_property> > >, boost::property<boost::edge_bundle_t, float, boost::no_property> > > >, boost::detail::sei_<unsigned long, std::_List_iterator<boost::list_edge<unsigned long, boost::property<boost::edge_bundle_t, float, boost::no_property> > >, boost::property<boost::edge_bundle_t, float, boost::no_property> > >(std::vector<boost::detail::sei_<unsigned long, std::_List_iterator<boost::list_edge<unsigned long, boost::property<boost::edge_bundle_t, float, boost::no_property> > >, boost::property<boost::edge_bundle_t, float, boost::no_property> >, std::allocator<boost::detail::sei_<unsigned long, std::_List_iterator<boost::list_edge<unsigned long, boost::property<boost::edge_bundle_t, float, boost::no_property> > >, boost::property<boost::edge_bundle_t, float, boost::no_property> > > >&, boost::detail::sei_<unsigned long, std::_List_iterator<boost::list_edge<unsigned long, boost::property<boost::edge_bundle_t, float, boost::no_property> > >, boost::property<boost::edge_bundle_t, float, boost::no_property> > const&) 2) boost::detail::postfix_increment_result<boost::counting_iterator<unsigned long, boost::use_default, boost::use_default>, unsigned long, unsigned long const&, boost::random_access_traversal_tag>::type boost::operator++<boost::counting_iterator<unsigned long, boost::use_default, boost::use_default>, unsigned long, boost::random_access_traversal_tag, unsigned long const&, long>(boost::iterator_facade<boost::counting_iterator<unsigned long, boost::use_default, boost::use_default>, unsigned long, boost::random_access_traversal_tag, unsigned long const&, long>&, int) -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
On Jun 27, 2007, at 1:51 PM, Ewgenij Sokolovski wrote:
Hello, I use the boost graph library (Version 1.33.1 of Boost) for my programming task. I wanted to profile my program with gprof. I compilated the source code with the -pg option and linked it also with that option. Now I'm examining the output file of gprof. Some functions of boost graph library are not explicitly listed there althogh I use them. These functions are:
vertices() add_edge()
What I see instead are some complicated functions. I have copied them here from my gprof-Output. But where are vertices() and add_edge()? Or are they meant by these complicated functions.
Profiling the BGL can be a scary exercise, as you've found... let's see if we can identify what these are:
1) std::pair<std::vector<boost::detail::sei_<unsigned long, std::_List_iterator<boost::list_edge<unsigned long, boost::property<boost::edge_bundle_t, float, boost::no_property> >
, boost::property<boost::edge_bundle_t, float, boost::no_property> , std::allocator<boost::detail::sei_<unsigned long, std::_List_iterator<boost::list_edge<unsigned long, boost::property<boost::edge_bundle_t, float, boost::no_property> > , boost::property<boost::edge_bundle_t, float, boost::no_property>
::iterator, bool> boost::graph_detail::push<std::vector<boost::detail::sei_<unsigned long, std::_List_iterator<boost::list_edge<unsigned long, boost::property<boost::edge_bundle_t, float, boost::no_property> > , boost::property<boost::edge_bundle_t, float, boost::no_property> , std::allocator<boost::detail::sei_<unsigned long, std::_List_iterator<boost::list_edge<unsigned long, boost::property<boost::edge_bundle_t, float, boost::no_property> > , boost::property<boost::edge_bundle_t, float, boost::no_property> , boost::detail::sei_<unsigned long, std::_List_iterator<boost::list_edge<unsigned long, boost::property<boost::edge_bundle_t, float, boost::no_property> > , boost::property<boost::edge_bundle_t, float, boost::no_property> (std::vector<boost::detail::sei_<unsigned long, std::_List_iterator<boost::list_edge<unsigned long, boost::property<boost::edge_bundle_t, float, boost::no_property> > , boost::property<boost::edge_bundle_t, float, boost::no_property> , std::allocator<boost::detail::sei_<unsigned long, std::_List_iterator<boost::list_edge<unsigned long, boost::property<boost::edge_bundle_t, float, boost::no_property> > , boost::property<boost::edge_bundle_t, float, boost::no_property> &, boost::detail::sei_<unsigned long, std::_List_iterator<boost::list_edge<unsigned long, boost::property<boost::edge_bundle_t, float, boost::no_property> > , boost::property<boost::edge_bundle_t, float, boost::no_property> const&)
The is one of the routines called by add_edge, named boost::graph_detail::push, which adds an element to a container.
2) boost::detail::postfix_increment_result<boost::counting_iterator<unsig ned long, boost::use_default, boost::use_default>, unsigned long, unsigned long const&, boost::random_access_traversal_tag>::type boost::operator++<boost::counting_iterator<unsigned long, boost::use_default, boost::use_default>, unsigned long, boost::random_access_traversal_tag, unsigned long const&, long> (boost::iterator_facade<boost::counting_iterator<unsigned long, boost::use_default, boost::use_default>, unsigned long, boost::random_access_traversal_tag, unsigned long const&, long>&, int)
This is the increment operator for the vertex_iterator type. I expect that this is just noise, because this routine would normally just inline to a single call to the increment operator for unsigned longs. - Doug
Hey, thanks a lot for your help! But why is impossible to profile BGL? As far as I know, normally all the standard libraries provide special compiled binaries, which are used for profiling when the -pg option is specified. Is it with boost not the case? And as far as I have understood the gprof tutorial, if I profile some program, but forget to compile a function f with the -pg option, then nevertheless f will be presented in the profiler output, but there will be no real information about it. But the name should appear! Or have I missed something? And why these two functions I listed are profiled, and other functions not? I mean the profiling should work either for all of them or for no one... Regards Ewgenij -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser
On Sat, 2007-06-30 at 12:45 +0200, Ewgenij Sokolovski wrote:
Hey, thanks a lot for your help! But why is impossible to profile BGL? As far as I know, normally all the standard libraries provide special compiled binaries, which are used for profiling when the -pg option is specified. Is it with boost not the case?
And as far as I have understood the gprof tutorial, if I profile some program, but forget to compile a function f with the -pg option, then nevertheless f will be presented in the profiler output, but there will be no real information about it. But the name should appear! Or have I missed something?
The problem is that the BGL data structures and algorithms use many small, inlined functions. These functions need to be inlined away for performance reasons, but that means that you don't get profiling information about them. If the compiler *did* put profiling information in them, it would be useless: the code of profiling these small routines exceeds the cost of the routines themselves, producing very misleading profiling information. - Doug
The problem is that the BGL data structures and algorithms use many small, inlined functions. These functions need to be inlined away for performance reasons, but that means that you don't get profiling information about them. If the compiler *did* put profiling information in them, it would be useless: the code of profiling these small routines exceeds the cost of the routines themselves, producing very misleading profiling information.
- Doug
Ah, gradually I can see the light at the end of the tunnel:) But if you read the tutorial on gprof, then you will see the following: If you compile only some of the modules of the program with `-pg', you can still profile the program, but you won't get complete information about the modules that were compiled without `-pg'. The only information you get for the functions in those modules is the total time spent in them; there is no record of how many times they were called, or from where. This will not affect the flat profile (except that the calls field for the functions will be blank), but will greatly reduce the usefulness of the call graph. http://www.cs.utah.edu/dept/old/texinfo/as/gprof.html#SEC2 So the names of the boost functions as well as the time spent inside of them should be shown in the profiler output. Although the corresponding libraries were not compiled with profiling options. Merely the amount of calls and caller names will be not available. But this is apparently not the case here. So what's wrong? And why these other two functions were in the profiler output? They were not called by my own function directly, so they should be somewhere lower in the hierarchy. Ewgenij -- GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail
On Sat, 2007-06-30 at 16:31 +0200, Ewgenij Sokolovski wrote:
If you compile only some of the modules of the program with `-pg', you can still profile the program, but you won't get complete information about the modules that were compiled without `-pg'. The only information you get for the functions in those modules is the total time spent in them; there is no record of how many times they were called, or from where. This will not affect the flat profile (except that the calls field for the functions will be blank), but will greatly reduce the usefulness of the call graph. http://www.cs.utah.edu/dept/old/texinfo/as/gprof.html#SEC2
So the names of the boost functions as well as the time spent inside of them should be shown in the profiler output. Although the corresponding libraries were not compiled with profiling options. Merely the amount of calls and caller names will be not available. But this is apparently not the case here. So what's wrong?
All of the code for the Boost Graph Library is in header files, so it's there in your compiled code. You're only seeing a few because those are the ones that were not inlined away. - Doug
Ah, OK. So if I get you right, the profiler does not profile inline functions in general? Independently on whether these functions are from boost.graph or not. So if I write some inline functions by myself they would not be profiled too. Do I understand it the right way? Ewgenij -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
On Sat, 2007-06-30 at 17:30 +0200, Ewgenij Sokolovski wrote:
Ah, OK. So if I get you right, the profiler does not profile inline functions in general? Independently on whether these functions are from boost.graph or not. So if I write some inline functions by myself they would not be profiled too. Do I understand it the right way?
If the compiler completely removes the functions (and their profiling information), yes. Compiler optimizations are rather unpredictable, so I can't tell you precisely what will happen. - Doug
participants (3)
-
Doug Gregor -
Douglas Gregor -
Ewgenij Sokolovski