performance analysis producer_consumer.cc TEST_T5

[Will Cohen]

law@redhat.com wrote:
> In message <4030DE6D.50607@redhat.com>, Will Cohen writes:
>  >I looked over the code a bit more. The tight loop that the code spends 
>  >most of its time is the result of the size() operation. The code is 
>  >counting the number of elements in the list.  The size() operation for 
>  >the list basically has to walk the linked list. The means of counting 
>  >the number of objects in other containers don't have a size() operation 
>  >that is O(n). The other size operations usually get a couple values, 
>  >subtract, and scale the result. There are two possible reasons I can 
>  >think of things going wrong with the list version as a result of the 
>  >size() operation not being atomic:
> Funny, a one of the customers you visited a couple weeks ago has complained
> repeatedly about not having an efficient means to get the number of objects
> on a list....
> 
> jeff
> 

The O(n) cost of list containers is certainly a drawback.
There is also a problem related to the threading with this particular 
performance test code. The uniprocessor machine the runtime was about 
1/30 the cpu time for the smp machine. If things were working correctly 
in the producer_consumer.cc code, the lists should be relatively short. 
That one function should not take 99.9% of the time (okay that is an 
exaggeration. it has 99.8996% of the samples for the test).

-Will