1

So I've used gprof to analyze my C++ code. The top three that make my code lag are as follows:

  %   cumulative   self                  self     total           
 time   seconds   seconds    calls      ms/call  ms/call     name    
 66.00    521.93   521.93 12674073276     0.00     0.00      std::_List_const_iterator<std::unique_ptr<Msg, std::default_delete<Msg> > >::operator++()
 13.63    629.70   107.77                                    _mcount_private
  9.47    704.63    74.93                                    __fentry__

I guess the second and the third are from gprof itself. But what does std::_List_const_iterator<std::unique_ptr<Msg, std::default_delete<Msg> > >::operator++() really mean? And why this causes slowness?

For reference, I have two important member variables:

std::list<std::unique_ptr<struct A> > queue_1;
std::vector<std::deque<std::list<std::unique_ptr<struct A> >::iterator > > queue_2;

So queue_2 is to store iterators to queue_1. There is supposed to be frequent push_back() and element deletions applied to the two queues.

vincentvangaogh
  • 354
  • 3
  • 11
  • 521 seconds / 12674073276 calls = 41ns per call - which doesn't seem entirely unreasonable, given that it also includes an atomic update of the number of calls and moving the iterator forward in the list. What time do you think it should take to update an iterator? – Mats Petersson Jul 28 '15 at 22:18
  • One can assume that the rest of the code is probably inlined, and as such don't get counted... So 41ns may be the total time that the loop takes, perhaps? If you actually posted some code we could look at, it's would be much more likely that we can comment on whether this is reasonable or not... How big is `struct A` for example? – Mats Petersson Jul 28 '15 at 22:20
  • Thanks for the quick reply. `struct A` contains 2 `enum`s, 10 `int`s, and 3 `double`s. Would this help? – vincentvangaogh Jul 28 '15 at 22:24
  • Really need to see what code the compiler is actually compiling. I expect the problem is that most of the code is not in functions at all, so `gprof` isn't recording it - it only records calls to functions, hence it looks like an `iterator++` is taking all the time. And if you are inserting 72 bytes into a queue, then I'd expect that there would be at least a dozen instructions involved just there. – Mats Petersson Jul 28 '15 at 22:49
  • I think the `gprof` is doing fairly well (?), since I have a function that also prints out the elapsed run time, which is 16 mins and 23 secs in total, close to the time recorded in the result file, which is 790.85 secs, or about 13 mins and 18 secs. Since 41ns is not unreasonable, I guess that's it. There are really a lot of operations on the two queues. I guess using `list` is really costly, compared to other containers? – vincentvangaogh Jul 28 '15 at 22:58
  • It's REALLY not easy to say if you are "doing well" or not - or what container works best for what you are doing... Or if there is a better way of doing what you want to achieve, in some other way... Without example code, it's all "Guess what I have in my suitcase" without opening the suitcase or knowing what might be in it... – Mats Petersson Jul 28 '15 at 23:09
  • It's not at all surprising that a) you have an iterator dominating your time, and b) that *gprof* doesn't tell you much. (I am curious what made you try *gprof* - was it a teacher, a book, the fact that you get it for free?) Anyway, the method many people use is [*random pausing*](http://stackoverflow.com/a/378024/23771). It costs nothing and tells you exactly why the time is being spent. – Mike Dunlavey Jul 29 '15 at 12:25
  • Isn't `gprof` kind of a "standard" analysis tool (?). I think I've found out why my code consumes a lot of time for `iterator++`. I used function `size()`, which is of O(n) complexity under older g++ (I was compiling on a server with old g++), and also function `distance()`, which seems to have O(n) complexity for all g++. I've rewritten my code and the run time is boost. Thank all for help. – vincentvangaogh Jul 29 '15 at 19:00
  • What "standard" means is lots of people agree on it for the reason that lots of other people agree on it. You will learn that there are valuable things to be found when you question common wisdom. [*Here is a list of the problems, not only with gprof, but with all the profilers that take it as a model.*](http://archive.is/9r927) If performance results are what you need, you need a better reason than just doing what is "standard". [*Here's the math behind it.*](http://scicomp.stackexchange.com/a/2719/1262) It is not easy to be a contrarian, but that is the secret of success. – Mike Dunlavey Jul 30 '15 at 00:22

0 Answers0