Meyers's preference for vectors over maps

[Fred Ma]

Hello,

I was looking at Meyers's "Effective STL", item 23
about choosing between vectors and maps (at least
that the choice for me). In many cases, using
sorted vectors is faster for lookups. The two
reasons are (1) that vector elements are smaller,
since map elements need at least 3 pointers, and
(2) contiguity of vector elements in memory ensure
fewer page faults.

For me, I will a container of objects that are much
bigger than pointers, so reason (1) doesn't apply.

Reason (2) is what I'm trying to understand better.
Let me describe my application.

In my case, I will have N items in the container,
will look up n (n<N) items, do some processing,
then replace the n worst items in the container
with the n new items from processing. Here, worse
is defined by the sorting function. The problem
is that n can vary from 1 to N, making the advantages
of vector vs. map very unclear. For small n,
map is better because I'm basically interspersing
1 modification of the database with 1 lookup.
For large n, vector is better because it's faster
to sort a whole bunch of objects at once rather
than building a map in a piecemeal fashion.

Since I can't get a clear answer from that line of
reasoning, I looked more carefully at Meyers's
reason (2). I will be using binary search for
lookup, and he claims that contiguity of elements
is good for binary search in particular. More
specifically, I understood him as meaning that
closeness of elements in memory should match
closeness of elements in the traversal of
container elements. However, my understanding
of binary search is that it doesn't traverse
elements in sequential order. So why the
contiguity of elements in a vector be of any
advantage?

Thanks for clarifying. And if there are any
other considerations that would make it easier
to decide upon a proper container, I'd appreciate
those too. Right now, I'm tempted to go for a
vector because I haven't used a map before. But
for that reason, I'm also thinking it's not a bad
reason to dabble in maps, too.

Fred
--
Fred Ma
Dept. of Electronics, Carleton University
1125 Colonel By Drive, Ottawa, Ontario
Canada, K1S 5B6

[Daniel T.]

Fred Ma <fm*@doe.carlet on.ca> wrote:

"Daniel T." wrote:

I guess the obvious answer is to create an adaptor that will allow you
to easily switch between the two. Then profile both and pick the most
efficient one.

I agree. Implementing both and profiling will certainly
determine the answer. And I would certainly like to
learn the profiler some time (it always seems like such
a luxury, time-wise, but it would immediately answer
lots of questions that can't be figured out otherwise).

For starters, I will hammer out a vector implementation.

For starters, you should design an interface that will make this special
queue of yours easy to use for the classes that use it. Then make it so
that you can switch out which kind of queue gets used by simply changing
one or two lines of code. *Then* hammer out a vector implementation.

This way, the endeavor isn't such a time waste. Instead it is a
opportunity to improve your design.

[Fred Ma]

"Daniel T." wrote:

Fred Ma <fm*@doe.carlet on.ca> wrote:

"Daniel T." wrote:

I guess the obvious answer is to create an adaptor that will allow you
to easily switch between the two. Then profile both and pick the most
efficient one.

I agree. Implementing both and profiling will certainly
determine the answer. And I would certainly like to
learn the profiler some time (it always seems like such
a luxury, time-wise, but it would immediately answer
lots of questions that can't be figured out otherwise).

For starters, I will hammer out a vector implementation.

For starters, you should design an interface that will make this special
queue of yours easy to use for the classes that use it. Then make it so
that you can switch out which kind of queue gets used by simply changing
one or two lines of code. *Then* hammer out a vector implementation.

This way, the endeavor isn't such a time waste. Instead it is a
opportunity to improve your design.

I believe it is not a waste of time either.
However, I have to prioritize the things I investigate.
I also have a deadline which I will miss if I try to
pursue too much in terms of expanding my C++ abilities
per se. I appreciate all the response, and my question
was posed more for a better understanding of the relevant
issues rather than solely determining the implementation
path I will choose. In fact, after some more reflection,
I think it's better to not even use a binary search (be it via
a map or binary searching a vector). I will first sort
the n elements I am searching for, then scan the N-element
lookup table for those elements (n<N). I after finding
the first sought-for element in the lookup table, I will
scan for the next sought-for element starting from that
point in the lookup table. On average, n=N/4, so that
means I scan an average of 4 consecutive elements before
encountering the next sought-for element. I can live with
that.

I'm sure there are more sophisticated ways that change
depending on the size of n and N, but again, the sort
and lookup is a tiny part of a much bigger problem, all
of whose aspects I will have to shortly and entirely
address. Thus the compromise in thoroughness of
investigating the sort/lookup, though I do appreciate
the thoughts on the things that matter for that problem.
There will certainly be situations in future in which I
will have to rely on the ideas that I've picked up in
this thread.

Fred
--
Fred Ma
Dept. of Electronics, Carleton University
1125 Colonel By Drive, Ottawa, Ontario
Canada, K1S 5B6

[Fred Ma]

Jerry Coffin wrote:

In article <40************ ***@doe.carleto n.ca>, fm*@doe.carleto n.ca
says...

[ ... ]

In my case, I will have N items in the container,
will look up n (n<N) items, do some processing,
then replace the n worst items in the container
with the n new items from processing. Here, worse
is defined by the sorting function. The problem
is that n can vary from 1 to N, making the advantages
of vector vs. map very unclear. For small n,
map is better because I'm basically interspersing
1 modification of the database with 1 lookup.
For large n, vector is better because it's faster
to sort a whole bunch of objects at once rather
than building a map in a piecemeal fashion.

Finding n smallest (or largest) items in a container can be done
considerably more quickly than simply sorting the container and then
taking the first (or last) n items. The latter requires a sort, which
is O(N lg N), where the former can be done in approximately O(n lg N)
time -- a big advantage if n is quite a bit smaller than N, and a
progressively smaller one as n approaches N.

The usual way of doing this is basically a modification of a Quick Sort.
In a Quick Sort, you pick a pivot, partition your elements, and then
recursively do the same with each partition.

To pick n elements instead, you simply pick the partition those elements
will fall into, and only recurse into the partition, ignoring the other.
For example, assume you want the 10 smallest elements out of 100. For
the moment I'll assume you pick perfect pivot elements every time, so
the first time you divide it into the 50 smallest and the 50 largest.
Clearly the 10 smallest aren't in the 50 largest, so you simply ignore
the right hand partition, and continue with the left partition. The
next time, you divide it into two groups of 25 elements apiece. Again,
you ignore the larger elements, and concentrate only on the smaller
ones. The next time around, you're down to 12 elements in the left
partition -- from there, it's probably easiest to just search linearly
to find the to largest of what's left, and discard them, leaving the 10
that you care about.

IIRC, whether this is better or worse than a heap depends on the
relative frequency of updating elements vs. inserting entirely new
elements. If (for example) you start with 100 elements, and every time
around, you insert 50 entirely new elements, find the 10 worst out of
the entire array, and so on iteratively, then chances are that this will
work better than a heap. At the opposite extreme, if the only updating
on the data is due to the processing you do after finding your n
elements, then chances are much better that a heap will work better.

A heap puts in a bit more work up-front, and does a partial sorting on
the entire array, so if you can put that to use, it will usually be a
win. OTOH, if you just search for n elements, you put less work into
arranging the data (so it's faster the first time) but you're leaving
the rest of the array relatively random, so you haven't gained much for
the next iteration.

Jerry, I am replacing the worst n of N elements (n<N) with new elements,
and I realize that partitioning is the way to go for that step (I am
going to use the partition() in STL for convenience). But prior to
this step, I lookup n out of N elements, and these are not the same
as the n worst elements. They can occur anywhere. I also neglected
to mention details which ultimately decided that binary searching (either
by a tree like a map, or binary search) is not the best way to perform
those lookups. That is, n will average N/4. What I will do is sort
the n elements to be looked up, then look for each one in turn by linearly
scanning the N elements of the lookup table. When one of the n elements
is found, the next one will be scanned for from that position in the lookup
table. So there will be an average of 3 skipped elements in the lookup
table for every one found. I take advantage of locality in the cache
more so than using a binary search, since the lookup table is traversed
sequentially, and the overhead of 3 skipped elements is acceptable because
of fast incrementing between adjacent vector elements.

I guess I'm exploiting a situation specific detail to get around the
larger question of profiling vector/map implementations for the time
being. The heap was a bit of a step which I prefer to find out more
about, but in the future. Reason being, my background is not CS, and
I posed my original choice as a vector/map decision because it's
readily available in standardized form via the STL, and I've got a
nice explanatory book about the formalities of their use in Josuttis.
So restricting my choices is a tradeoff; certainly, I won't have the
best solution, but I can choose the best one for which I can allot
the time.

Thanks for explanation of partitioning, and examples comparing it to
the heap (though I have to admit, I need to follow it up with more
textbook reading--I've briefly read about heaps in the past when
pondering the sort/lookup problem).

Fred
--
Fred Ma
Dept. of Electronics, Carleton University
1125 Colonel By Drive, Ottawa, Ontario
Canada, K1S 5B6