473,703 Members | 2,361 Online

factor 50.000 between std::list and std::set?

If I have a sorted std::list with 1.000.000 elements it takes 1.000.000
operations to find element with value = 1.000.000 (need to iterator
through the whole list).

In comparison, if I have a std::set with 1.000.000 element it will only
take approx lg 1.000.000 = 20 operations! Can it really be true that the
difference is a factor of 1.000.000/20 = 50.000 in this case?
Jun 25 '07 #1
15 4149
desktop wrote:
If I have a sorted std::list with 1.000.000 elements it takes 1.000.000
operations to find element with value = 1.000.000 (need to iterator
through the whole list).

In comparison, if I have a std::set with 1.000.000 element it will only
take approx lg 1.000.000 = 20 operations! Can it really be true that the
difference is a factor of 1.000.000/20 = 50.000 in this case?
Yes. Now do the same exercise, but look for the first element. The
difference isn't as dramatic, but it's there.

--

-- Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." (www.petebecker.com/tr1book)
Jun 25 '07 #2
desktop wrote:
If I have a sorted std::list with 1.000.000 elements it takes 1.000.000
operations to find element with value = 1.000.000 (need to iterator
through the whole list).

In comparison, if I have a std::set with 1.000.000 element it will only
take approx lg 1.000.000 = 20 operations! Can it really be true that the
difference is a factor of 1.000.000/20 = 50.000 in this case?
Yes. A list is a linear search, aka O(N) to find an element. A set is
required to have logarithmic time search O(log N). So a times specified
make perfect sense.
Jun 25 '07 #3
Pete Becker wrote:
desktop wrote:
>If I have a sorted std::list with 1.000.000 elements it takes
1.000.000 operations to find element with value = 1.000.000 (need to
iterator through the whole list).

In comparison, if I have a std::set with 1.000.000 element it will
only take approx lg 1.000.000 = 20 operations! Can it really be true
that the difference is a factor of 1.000.000/20 = 50.000 in this case?

Yes. Now do the same exercise, but look for the first element. The
difference isn't as dramatic, but it's there.
Well in a sorted list it takes constant time. But in the set it might
take 20 operations, unless you use some kind of header that always have
pointers to min and max. But still a factor 50.000 seems supernatural in
the previous example!
Jun 25 '07 #4
On 2007-06-25 22:21, desktop wrote:
If I have a sorted std::list with 1.000.000 elements it takes 1.000.000
operations to find element with value = 1.000.000 (need to iterator
through the whole list).

In comparison, if I have a std::set with 1.000.000 element it will only
take approx lg 1.000.000 = 20 operations! Can it really be true that the
difference is a factor of 1.000.000/20 = 50.000 in this case?
In operations yes, not necessarily in time. If the operations on the
list takes 1 time and the operations on the set takes 50,000 then
they'll be equally fast. This will of course not be true in any
implementation (the set will be significantly faster than the list) but
it shows that just because one container/algorithm has a better
asymptotic running time it will in fact perform better. All it says is
that for a sufficiently large set of input, the algorithm will perform
better.

In practice you'll often find that using a vector for small sets will be
faster than most other containers, even if you need to traverse the
whole vector.

--
Erik Wikström
Jun 25 '07 #5
Erik Wikström wrote:
On 2007-06-25 22:21, desktop wrote:
>If I have a sorted std::list with 1.000.000 elements it takes
1.000.000 operations to find element with value = 1.000.000 (need to
iterator through the whole list).

In comparison, if I have a std::set with 1.000.000 element it will
only take approx lg 1.000.000 = 20 operations! Can it really be true
that the difference is a factor of 1.000.000/20 = 50.000 in this case?

In operations yes, not necessarily in time. If the operations on the
list takes 1 time and the operations on the set takes 50,000 then
they'll be equally fast. This will of course not be true in any
implementation (the set will be significantly faster than the list) but
it shows that just because one container/algorithm has a better
asymptotic running time it will in fact perform better. All it says is
that for a sufficiently large set of input, the algorithm will perform
better.

In practice you'll often find that using a vector for small sets will be
faster than most other containers, even if you need to traverse the
whole vector.
Is it possible to make an exact measurement in the difference in time
for 1 operation for a set and a list?
Jun 25 '07 #6
On Jun 25, 3:51 pm, desktop <f...@sss.comwr ote:
Erik Wikström wrote:
On 2007-06-25 22:21, desktop wrote:
If I have a sorted std::list with 1.000.000 elements it takes
1.000.000 operations to find element with value = 1.000.000 (need to
iterator through the whole list).
In comparison, if I have a std::set with 1.000.000 element it will
only take approx lg 1.000.000 = 20 operations! Can it really be true
that the difference is a factor of 1.000.000/20 = 50.000 in this case?
In operations yes, not necessarily in time. If the operations on the
list takes 1 time and the operations on the set takes 50,000 then
they'll be equally fast. This will of course not be true in any
implementation (the set will be significantly faster than the list) but
it shows that just because one container/algorithm has a better
asymptotic running time it will in fact perform better. All it says is
that for a sufficiently large set of input, the algorithm will perform
better.
In practice you'll often find that using a vector for small sets will be
faster than most other containers, even if you need to traverse the
whole vector.

Is it possible to make an exact measurement in the difference in time
for 1 operation for a set and a list?- Hide quoted text -

- Show quoted text -
sure, just write a benchmark test. There is no more precise way,
because of course the time depends on your CPU, your compiler, your
operating system, and what appliactions are running at the time. A
simple test like the following should work (on windows).

std::vector<int intVector;
populateIntVect or(&intVector);
std::set<intint Set;
populateIntSet( &intSet);

DWORD d = timeGetTime();

for (int i=0; i < 1000000; ++i)
{
// Perform Vector operation
}

DWORD d2 = timeGetTime();

for (int i=0; i < 1000000; ++i)
{
// Perform set operation
}

DWORD d3 = timeGetTime();

DWORD millisecondsFor Vector = d2 - d;
DWORD millisecondsFor Set = d3 - d2;

double millisecondsFor SingleVectorOp = (double)millise condsForVector /
(double)1000000 ;
double millisecondsFor SingleSetOp = (double)millise condsForSet /
(double)1000000 ;

Jun 25 '07 #7
Zachary Turner wrote:
On Jun 25, 3:51 pm, desktop <f...@sss.comwr ote:
>Erik Wikström wrote:
>>On 2007-06-25 22:21, desktop wrote:
If I have a sorted std::list with 1.000.000 elements it takes
1.000.000 operations to find element with value = 1.000.000 (need to
iterator through the whole list).
In comparison, if I have a std::set with 1.000.000 element it will
only take approx lg 1.000.000 = 20 operations! Can it really be true
that the difference is a factor of 1.000.000/20 = 50.000 in this case?
In operations yes, not necessarily in time. If the operations on the
list takes 1 time and the operations on the set takes 50,000 then
they'll be equally fast. This will of course not be true in any
implementatio n (the set will be significantly faster than the list) but
it shows that just because one container/algorithm has a better
asymptotic running time it will in fact perform better. All it says is
that for a sufficiently large set of input, the algorithm will perform
better.
In practice you'll often find that using a vector for small sets will be
faster than most other containers, even if you need to traverse the
whole vector.
Is it possible to make an exact measurement in the difference in time
for 1 operation for a set and a list?- Hide quoted text -

- Show quoted text -

sure, just write a benchmark test. There is no more precise way,
because of course the time depends on your CPU, your compiler, your
operating system, and what appliactions are running at the time. A
simple test like the following should work (on windows).

std::vector<int intVector;
populateIntVect or(&intVector);
std::set<intint Set;
populateIntSet( &intSet);

DWORD d = timeGetTime();

for (int i=0; i < 1000000; ++i)
{
// Perform Vector operation
}

DWORD d2 = timeGetTime();

for (int i=0; i < 1000000; ++i)
{
// Perform set operation
}

DWORD d3 = timeGetTime();

DWORD millisecondsFor Vector = d2 - d;
DWORD millisecondsFor Set = d3 - d2;

double millisecondsFor SingleVectorOp = (double)millise condsForVector /
(double)1000000 ;
double millisecondsFor SingleSetOp = (double)millise condsForSet /
(double)1000000 ;
But would that not show the asymptotic difference and not the "constant"
difference in time to execute a single operation?
Jun 25 '07 #8
desktop <ff*@sss.comwro te in news:f5******** **@news.net.uni-c.dk:
Pete Becker wrote:
>desktop wrote:
>>If I have a sorted std::list with 1.000.000 elements it takes
1.000.000 operations to find element with value = 1.000.000 (need to
iterator through the whole list).

In comparison, if I have a std::set with 1.000.000 element it will
only take approx lg 1.000.000 = 20 operations! Can it really be true
that the difference is a factor of 1.000.000/20 = 50.000 in this
case?
>>
Yes. Now do the same exercise, but look for the first element. The
difference isn't as dramatic, but it's there.

Well in a sorted list it takes constant time. But in the set it might
take 20 operations, unless you use some kind of header that always have
pointers to min and max. But still a factor 50.000 seems supernatural
in
the previous example!
Why is that supernatural? Searching a std::list is an O(n) operation,
searching a std::set is O(ln n) operation. As you increase n, the O(n)
grows faster than the O(ln n) (Try it with an O(n!) and see what happens
to the differences.... )

std::list doesn't have a random-access iterator, only bidirectional.
Thus you must at least traverse the entire list (in the worst case). You
may be able to get away with O(ln n) comparisons in the list if you have
the assumption that the list is sorted, and you use a binary search
algorithm.

std::set is likely stored in some sort of tree-like structure, and thus
gets the tree's efficiency in searching, O(ln n).
<tanget>Althoug h this is a brilliant example of how optimization tends to
be more effective if you change algorithms vs. attempting to tune the
existing algorithm.</tangent>
Jun 25 '07 #9
Andre Kostur wrote:
desktop <ff*@sss.comwro te in news:f5******** **@news.net.uni-c.dk:
>Pete Becker wrote:
>>desktop wrote:
If I have a sorted std::list with 1.000.000 elements it takes
1.000.000 operations to find element with value = 1.000.000 (need to
iterator through the whole list).

In comparison, if I have a std::set with 1.000.000 element it will
only take approx lg 1.000.000 = 20 operations! Can it really be true
that the difference is a factor of 1.000.000/20 = 50.000 in this
case?
>>Yes. Now do the same exercise, but look for the first element. The
difference isn't as dramatic, but it's there.
Well in a sorted list it takes constant time. But in the set it might
take 20 operations, unless you use some kind of header that always have
pointers to min and max. But still a factor 50.000 seems supernatural
in
>the previous example!

Why is that supernatural? Searching a std::list is an O(n) operation,
searching a std::set is O(ln n) operation. As you increase n, the O(n)
grows faster than the O(ln n) (Try it with an O(n!) and see what happens
to the differences.... )

std::list doesn't have a random-access iterator, only bidirectional.
Thus you must at least traverse the entire list (in the worst case). You
may be able to get away with O(ln n) comparisons in the list if you have
the assumption that the list is sorted, and you use a binary search
algorithm.
What algorithm are you referring to? "search":

http://www.cppreference.com/cppalgorithm/search.html

runs in linear time and quadratic in worst case.

I assume there exists no algorithm that can find an element in a list in
O(lg n) time (maybe if the list is sorted but that does not correspond
to the worst case).

>
std::set is likely stored in some sort of tree-like structure, and thus
gets the tree's efficiency in searching, O(ln n).
<tanget>Althoug h this is a brilliant example of how optimization tends to
be more effective if you change algorithms vs. attempting to tune the
existing algorithm.</tangent>
Don't you mean change container/structure instead of algorithm?
Jun 25 '07 #10

This thread has been closed and replies have been disabled. Please start a new discussion.